Is there any standardized way in Delphi mobile apps for storing/syncing app data across mobile phones for Android + iOS?
Here is my siuation:
Currently I ship some data with my apps and new data is downloaded to cache. This works well, also when users download new versions.
However, now I need to store data inputted by the user... Thus data needs to be persistent... And ideally it should survive mobile changes, e.g. from ios to android or at east when upgrading from e.g. iphone5 to iphone6. I rather not host user data myself on my own servers. It it also important that it is cost free.
So I am looking at what is necessary for:
App/user data survives upgrading Android phone keeping Google Play account.
App/user data survives upgrading iphone keeping Apple iTunes account.
App/user data when user changes mobile platform.
I guess a combination of these solutions will be necessary:
Using a cloud service tied to each separate plaform (i.e. iCloud for iPhone users)
Make an import/export function to a data folder the user manually can backup when switching from e.g. Android o iPhone or the other way
The minimal but fully acceptable solution would be an easy way to export/import a data file. That data file could then e.g. be stored in any service where it could be retrievd from later?
The amount of data will not be a whole lot. Each user has his/hers own data. If the user uses multiple devices it will be up to the user to export/import/sync data in a way that makes senses.
Related
We are looking to rewrite a form-based application with a fairly tight time-scale (ideally, we would be launching the beta mid-July, and the final version by September). The current platform is showing its limitations and would require an exorbitant amount to bring into line with our requirements. As such, we are looking to bring the technology in-house, and writing our own solution.
Requirements:
Must be able to handle loss of network connectivity - the user may not always have internet access
Must have secure two-way communication with the server - the information being uploaded and downloaded can contain personal information, and it is imperative that we not be responsible for data-loss
Must be able to synchronise and update / remove records already on the tablet - the information can change, and the user must have access to information as "fresh" as possible
Must be able to store a large number of records (~1000+ records, a few kB each, so total 5+ MB) offline - depending on the tablet model, the user may only have internet access via wifi at the beginning and end of a day, so as many records as might be accessed should be downloaded and stored
Should be accessible on both iOS and Android
The solution we have currently is a form app, which fails heavily on point three, which is rapidly becoming a deal-breaker. The solutions that have been floated are:
An HTML5 website with offline capabilities, through the tablet's web browser
A website wrapped in an off-the-shelf app "shell" to provide offline capabilities, deployed through the app stores
A custom-built app (through Xamarin or similar) to be deployed through the app stores
Unfortunately, we are a company of desktop developers - we have no in-house experience with tablet applications currently. That being said, the application is tied very closely with several of our other products, so it would be difficult to outsource the development.
The question, therefore, is this:
As a mobile application developer, what approach would be "recommended" to build an offline-capable app that must communicate securely with a server when it can?
So for 5 mb of data that needed to be synchronized, I would build an web service from where you can get the data for your mobile application.
I prefer JSON Format for the data.
When your app logs in while internet connection, the app can fetch the complete data from the web service.
What I do then, is to compress or archive the json as file to the app internal filesystem.
Now there are only two scenarios for the app:
offline (login):
get the archived json file and do what you want with your data
online (login)
fetch the data again from the web service, archive it and then do what you want with your data
To synchronize the data back to the backend is not really mobile application stuff. You have to think about your architecture in the backend.
For security ensure you have ssl enabled for the connection to the web service.
I am native iOS developer but I build something similar with Symfony as Backend and three native applications (iOS, Android and Windows)
You could also use firebase as a backend, it really depends on your needs.
At the end, im just a stranger from the internet :) and normally when a customer needs an estimation, we really need time for such an estimation and to choose the right platforms that fits for the customer.
I know this is not a straightforward solution question, but I do need expert opinions regarding this since I could not find the solution anywhere on the net.
We have a platform that exposes services via REST and we build applications on top of this platform (both HTML and Android). Now we help build android applications for different customers and the app base is growing with time.
What I have found is that for most of these apps, the tables used to store local data are the same and in many cases one android app is dependent on the other android app on the same device for data and in many cases the apps will be offline. For ex: App1 and App2 are installed, App1 gathers data which maybe required for App2 before the data is synced to the servers. So I have an idea of making this data common between apps regardless of which app is installed on the device.
The concept is to have a common service running in the background which provides an interface to other client apps either via content providers or AIDL. All the data of the apps installed on the device will be managed by this common service. Of course there will be differentiating factors like app id, context id, user id etc., to maintain the integrity of the individual app data.
Reasoning behind the architecture is,
1) Reduces redundancy of the tables involved.
2) Any app can query the data of any other app using the app id.
3) Sync can be offloaded to this common service and dependency on data can be easily managed.
4) updates to data management layer in the apps can be easily managed by updating a single application.
5) Improves the productivity of an app developer since he/she does not have to worry about managing data offline or syncing it to our servers.
Disadvantages that I could come up with are
1) Single point of failure for all the applications.
2) Data transfer between apps may be slow (Just a feeling).
What do you guys think about this approach? Please highlight advantages or disadvantages and if there are alternate approaches.
Apologies for the long post, let me know if I have violated any forum guidelines.
In a normal android app ,we can code and create a sqlite database for an android app,But when we are putting this app on play store and multiple users are using that app, then how can we provide same kind of data to all users as database(sqlite) we made is only to that user in his phone.
I am new to android programming so not sure how to maintain a centralized database.
If you want centralized data for all users of your app, regardless of the device, then you'll need to use a cloud type API (e.g. web app backend accessed via REST API). Anything you put in a SQLite database on the device will only be accessible by that app on that specific device and for that specific person. On Android devices with multiple people, such as a tablet with multiple profiles, each person gets a separate instance of your app and data.
I'm looking for a solution to synchronize data between iOS and Android apps.
Maybe exist web-services with iOS and Android libs for this purpose?
EnduroSync from Orando Labs is a new product that does exactly what you are asking. There are clients for iOS and Android, with more coming.
Full Disclosure: I work at Orando Labs.
The EnduroSync clients allow you to create object data stores on the local devices. The clients are fairly sophisticated - data is modeled as native objects for each client we support (iOS and Android now, more coming). The clients work offline and online. The data is saved to an sqlite database locally.
As you change objects in your model, the deltas are recorded on the device. At some point, you can 'sync' the object data store. Syncing uses a commit/push/pull process (like git), but this is invisible to you. The sync brings your local copy up to date with whatever is on the server, and sends up any changes you have made. Conflicts are resolved using a timestamp based merge, so newer data is not overwritten by older data.
EnduroSync is an online service, so there is no server setup on your end.
There is also a flexible permission system which lets you share the object data stores in a variety of ways. For instance, most applications will have one or more object data stores for each user, for preferences, notes, tags, etc. You can also share object data stores per app, per user type, and with wild cards, many other ways.
So basically you use our client SDK's to model your data on the device. Modeling is with simple objects in the native programming language of the device. If you sign up for the syncing service, you get the syncing also.
I found the solution: https://parse.com/products/core The service also has social integration like facebook login, etc.
I am studying the feasibility of developing a mobile application for Android, for traders, where the client-side installs on a smartphone (A) and of course, through Google Play, and server-side installs itself in another smartphone (B) that installs via the Play also.
B through the merchant takes pictures of your items and upload adding a description (this article) for the application server side, in ways that the user A, which has the side application client can enjoy the products.
In short:
Capturing data to the server must be made through an Android phone that can take pictures of products and upload to the system and adding text to describe the product.
Consultation of products will be made by a mobile phone with Android as well.
Is it possible to do this? If not, I would appreciate to give me suggestions on how to do this. But I wanted to try not to make using computers (PC / Mac) or web app to load the data to the application. I want a system purely mobile. Maybe will use the computers to store the BD system only.
When you say the server side is a phone app, you imply that the phone is always on, the app is always running, and you need no central storage whatsoever.
You also lose any ability to keep analytics for your service, which is a crucial part of any startup.
If you want your app to have the server available even 80% of the time, and you want to keep a central database of what's going on, you must have some server you can control.
There are a lot of very cheap and manageable cloud solutions, so you don't need to buy an actual server.