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.
Related
When I build a web application, like most others, I simply build an admin area from which the client can control their site.
Most applications I build for android never require this kind of maintenance as they are all self contained. However Something I'm extremely curious about, say you build a cross platform application that does require constant maintenance; you've got 2 versions - an iOS and android version. What would be the best way to go about managing both applications from the same place?
For examples sake, let's say you build a real simple application. It could be something that once a day sends you a message, "hope you're day is going well" or "let me tell you a joke". Now what if those messages were hand typed and submitted to the applications, you want to log into a system, type the daily message in and both applications are simultaneously updated with the new message.
In my head I'm imagining you would need to build a dedicated admin system either as a web application or standalone desktop application that connects to the apps hosted database however I'm wondering about how well that would work, what kind of problems are you going to run Into, would it even be feesable?
I've never had to build something like this but some of the more recent web applications I've built would work well as straight forward applications and that just gets me thinking, if I was asked to turn them into apps that function the way they do already, what would be the best way?
It's something I'm really curious about and feel like I need to get my understanding on the right track.
I think you are describing an application for an admin that will set up (write) data to be used by users of Android and IOS apps. Few options:
Write the admin application as a regular web application. Be careful to use transactions in the code that writes to the database. That is to avoid inconsistent DB states when your admin applications DB writes interleave between mobile app reads. Also you have to secure the admin REST resources (API end points) for admin access only, so you would need authorization code in the app.
Write admin apps for the mobile platforms (or an admin section in the existing app that is properly authorized in the app code) and the server API end points. That is more tedious because of 2 platforms. Again you will need the DB transactions and authorization code
Write separate admin apps for mobile but with one framework (Xamarin). It will work for simple apps and yours sounds simple enough for Xamarin to work well.
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.
For a simple app that has a list of (for example) stores, how are the CRUD operations implemented? Would a desktop/web manager app be the solution?
For example, the manager has all the CRUD implementations while the mobile app just displays and process search queries.
EDIT:
Lets say I am making an application for android that shows users where the best vegetables can be obtained within a 10 mile radius, such application would only have a list of stores, a search bar and perhaps a simple sistem for more narrow queries (like the organic etc...)
Naturally I'll want to add, edit and delete the record of stores that the app shows, but I don't want to even show a link or option to manage the app on the user interface for security reasons.
I was considering building a basic desktop app that manages the CRUD operations, whereas the mobile one just periodically updates the information to reflect changes if any.
This is my first mobile app so I am not quite sure how this is often deal with.
The answer for this question is very contextual. The answer is, it depends!
Is the data meant to exist only on the application itself? If so, I'd look into sqllite database management.
Is the data meant to be used on a web application aswell? If so I'd look into implementations such as parse (and many others) that will handle the persisting of the data.
Perhaps you have the data on the database already, maybe your next step is building a restful api to interact with said data
i am creating simple android apps like student registration.
suppose i registered three students data in mobile.(insert data).
then how all teachers can see student list. all teachers have same application install.
Thanks.
It is common for applications to offer features such as backup storage, data sync, data sharing etc. Building stand alone applications that only function and save their data on the device they are installed on is at times not feasible. A backend is usually needed where data can be saved and manipulated for the app to provide the service it was intended for.
Building this requires time, a different skill set and other resources (e.g. servers, push notification services, etc). Fortunately, there are several platforms that provide ready-made customizable backends that you can integrate with your apps. These are known as ‘Backend as a Service’, or BaaS in short.
we are going to look at using Parse to provide a backend for an Android application. We’ll briefly look at what it offers before building an application that will use it for user registration, authentication and storing of user data.
you can follow this link to learn more :
http://www.sitepoint.com/creating-cloud-backend-android-app-using-parse/
or You can see :
http://blog.parse.com/2014/04/30/take-your-app-offline-with-parse-local-datastore/
I'm currently developing my first Android application and still in the designing stage trying to come up with a solid model.
My application will use the GCal data from a users Google calendar and sync it up with one or more other users to determine common meeting times between all without the tedious back and forth of scheduling over email.
I vision this working by storing each user and their calendar data in a database that will be refreshed daily. When a query to determine the optimal meeting times between a group is issued, I want to select the calendar data of each user from the database, perform the computation to find optimal times, and display the results back to the user who made the query.
The AWS SDK for Android supports Amazon SimpleDB and S3, in which case I would use SimpleDB for my database. Where I am getting lost is using the Amazon EC2 web service in concert with the SimpleDB to perform the computation.
First off, any feedback on my approach and/or design is appreciated.
Second, how does using non-Android, but Java based APIs/SDKs effect applications, or is it even possible to do so?
The API typica for Java looks interesting and useful if it is possible to use with Android for instance.
Thanks!
So, I think its important to note a couple of things.
What you are describing is not an 'android application'. Its a web service application with an android client. The reason I'm being pedantic is that many of the design decisions you need to make are completely besides the fact that your primary client will run on android.
I'm concerned about the viability of storing the users calendar in a non-relation database. I don't know if you've already looked through this, but the problem you are trying to solve (calendaring) seems like it would benefit from the relational benefits of a relational database. For instance, i'm not sure how you would structure for storage the data of past, present and future events/meetings in a non-relational. Its probably possible, but i'm not sure if its optimal. Depending on the amount of data you may also need to consider the maximum record size.
While its true that AWS SDK for android supports writing to S3 or SimpleDB, I think there is a lot to consider. The reason you are confused about the interaction with EC2 is that normally, your EC2 web service will be interacting with S3 or SimpleDB. By using the AWS SDK you can, in theory, remove the requirement for a web service. My main issue with that is that you're now forced to do lots more on each client because there is no common access pattern. Your ios client or web client needs to have all the same logic that your android client has to make sure its accessing your s3 and simple db data the same. If that doesn't make sense i can elaborate.
Using non-android api's and sdks is a mixed bag. Sometimes it works fine if the classes compile to Davlik. If they don't it doesn't work.
One thing I might point out, since you'll already possibly be tied to a Google technology is Google App Engine. The nice part about it is that there is a free level of service which lets you get your app up and running without cost. Based on the technologies you are suggesting, it might be something for you to look into. Other than that, my other strong suggestion is that you focus on building out the web service first and independently of the android client. Take the time to model what the client server interaction would be and move as much of the 'logic' to the server as is possible. Thats what I felt like was missing from your initial description. Where the crunching would be.
my solution is that you use O-O principles. store your db on amazon dynamoDB and then sync user data with the mobile app. then you do processing of the data/computation on the device before displaying the results