Can I sync a SQLite.swift database to WatchOS? - swift3

I have an application that uses SQLite.swift to save a list of shopping items. It works quite well, and is deeply rooted in the app. But I've been getting asked to make a WatchOS app that has the same items on your wrist.
My issue with this, is that all the ways of syncing the data between two devices is through NSUserDefaults. But doing that would mean uprooting my entire way of saving data, so is there a way to sync my SQL database onto WatchOS by using SQLite.swift?

Yes of course: sync the database (or the shared part of it) yourself.
Read the "Communicating with the Counterpart App" chapter of https://developer.apple.com/reference/watchconnectivity/wcsession and choose the best way to transfer your information.

Related

Where/how to store frequently updated data feeding shiny apps?

I built a shiny app which works with data that needs frequent update. The app doesn't change, just the data. At the beginning, i used to update my data locally, and republish my app every time the data had been updated, which i quickly found quite annoying.
I then started to store my datasets online (on arcgis online, for various reasons) so that i wouldn't need to republish my shiny app anymore, just need to handle the process of data updates.
The problem is that my app is quite slow as the datasets are very big.
Now i would like to transform my datasets as api's so that the requests coming from shiny could be more targeted.
But i don't know really know to do that. Handling the update of datasets on arcgis online through an R script was fine. But updating the same datasets as hosted feature service, i can't make it work.
Would anyone have an idea?
Or more general question, if moving away from my Arcgis online storage, what would be the best way to store data that needs frequent updates and that feed shiny apps?
You can look into caching data using 'Pins' package

What is the "proper" way to use DynamoDB for an iOS app?

I've just started messing around with AWS DynamoDB in my iOS app and I have a few questions.
Currently, I have my app communicating directly to my DynamoDB database. I've been reading around lately and people are saying this isn't the proper way to go about getting data from my database.
By this I mean is I just have a function in my code querying my Dynamo database and returning the result.
How I do it works but is there a better way I should be going about this?
Amazon DynamoDB itself is a highly-scalable service and standing up another server in front of it requires scaling the service also in line with the RCU/WCU configured for your tables, which we can and should avoid.
If your mobile application doesn't need a backend server and you can perform all the business functions from the mobile device, then you should probably think about
Using the AWS DynamoDB SDK for iOS devices to write your client application that runs on the mobile device
Use AWS Token Vending Machine to authenticate your mobile users to grant them credentials to be used to run operations on DynamoDB tables.
Control access (i.e what operations should be allowed on tables etc.,) using IAM policies.
HTH.
From what you say, I can guess that you are talking about a way you can distribute data to many clients (ios apps).
There are few integration patterns (a very good book on this: Enterprise Integration Patterns), one of which is called shared database. It is essentially about using a common database for multiple clients to share the data. Main drawback for that pattern (in your case) is that you are doing assumption about how the database schema looks like. It can potentially bring you some headache supporting the schema in the future, if your business logic changes.
The more advanced approach would be sending events on every change in your data instead of directly writing changes to the database from client apps. This way you can add additional processing to the events before the data they carry is written to the database. For example, you may want to change the event format in the new version of your app, but still want to support legacy users, so you add translation procedure which transforms both types of events to the format which fits the database schema. It's basically a question of whether to work with diffs vs snapshots.
You should be aware of added complexity of working with events, and it can be an overkill if your app is simple and changes in schema are unlikely.
Also consider that you can do data preprocessing using DynamoDB Streams, which gives you some advantages of using events still keeping it simple to implement.

What CloudKit do and don't regarding multi user App

First I am new in Xcode but start using Swift
I am so confused with the purpose of CloudKit (Document) if I want to develop multiuse app. Which normally I would use Web Services or Web base Application. It would be nice to use App in mobile and store all data in Cloud.
I have two questions:
Regardless of speed to deal with the iCloud, Can I make app with most or all data in iCloud and go to Appstore. Mean App only run when network available. (The reason I asked because some developers complained of Apple rejected with the reason "Specifically, your application requires iCloud support for the users to access this application, which can create poor user experience. ")
In case the app should maintain the syn of all data. I couldn't imagine how complicate to handle all in/out of the data. So the question: Is there any way to replicate iCloud data. just like some databases: MySql, Sql without much of the programming. Then I just focus on CoreData with replication features.
Concerning availability CloudKit is not very different from using web services. If there is no internet connection, then you will not be able to fetch data. How would you handle that if you were using web services? You should handle it the same way when using CloudKit. Just make sure that at least there is some functionality when the data is not available.
Your 2nd question is a bit broad. Yes, you could use CoreData syncing to iCloud. You could also just catch the fetched data using one of the many caching libraries that car available (search CocoaPods)

Django website serving data to mobile app

I am currently trying to figure out he best practice in order to design my web services between a django administrated database (+ images) and a mobile app. My main concern is how to separate a bulk update (send every data in the database and all the files on the server) and a lighter, smaller update with only the new and / or modified objects (images or data.)
I have had access to a working code-base using a cronjob and states for each data field (new, modified, up to date) to generate either a reference data file or an update file. I find it to be very redundant and somewhat unelegant, in contradiction with the DRY spirit of Django (there are tons of lines of code, making it nearly unmaintainable.))
I find it very surprising that this aspect is almost un-documented, since web traffic is a crucial matter in mobile developpment.. Fetching everytime all the data served quickly becomes unsustainable as the database grows..
I would be very grateful for any lead or advice you could give me :-) Thx in advance !
Just have a last_modified DateTimeField in your table, and in your user's profile a last_synchronized DateTimeField. When the mobile app wants to synchronize, send the data which was modified after the last synchronization run, and update the last_synchronized field in the user's profile.

Sync Framework Considerations for Smart Client app

Microsoft Sync Framework with SQL 2005? Is it possible? It seems to hint that the OOTB providers use SQL2008 functionality.
I'm looking for some quick wins in relation to a sync project.
The client app will be offline for a number of days.
There will be a central server that MUST be SQL Server 2005.
I can use .net 3.5.
Basically the client app could go offline for a week. When it comes back online it needs to sync its data. But the good thing is that the data only needs to push to the server. The stuff that syncs back to the client will just be lookup data which the client never changes. So this means I don't care about sync collisions.
To simplify the scenario for you, this smart client goes offline and the user surveys data about some observations. They enter the data into the system. When the laptop is reconnected to the network, it syncs back all that data to the server. There will be other clients doing the same thing too, but no one ever touches each other's data. Then there are some reports on the server for viewing the data that has been pushed to the server. This also needs to use ClickOnce.
My biggest concern is that there is an interim release while a client is offline. This release might require a new field in the database, and a new field to fill in on the survey.
Obviously that new field will be nullable because we can't update old data, that's fine to set as an assumption. But when the client connects up and its local data schema and the server schema don't match, will sync framework be able to handle this? After the data is pushed to the server it is discarded locally.
Hope my problem makes sense.
I've been using the Microsoft Sync framework for an application that has to deal with collisions, and it's miserable. The *.sdf file is locked for certain schema changes (like dropping of a column, etc.).
Your scenario sounds like the Sync Framwork would work for you, out of the box... just don't enforce any referential integrity, since the Sync Framework will cause insert issues in these instances.
As far as updating schema, if you follow the Sync Framework forums, you are instructed to create a temporary table the way the table should look at the end, copy your data over, and then drop the old table. Once done, then go ahead and rename the new table to what it should be, and re-hookup the stuff in SQL Server CE that allows you to handle the sync classes.
IMHO, I'm going to be working on removing the Sync functionality from my application, because it is more of a hinderance than an aid.