I'm fairly new to android but I have some J2EE experience. I am working on an android application and my model makes use of the composite pattern, and in addition some of the objects will contain a list of other objects. I understand when dealing with mobile apps, I won't have as much memory available and when looking at my design, I will probably end up loading a lot of objects in memory with my current models when I'm querying the sqllite database. So my question is for people who have worked in both worlds, did you have to make changes in the way you deal with objects (how you populate them from the database etc...) to make the application run faster?
Thanks!
Not really. You can use SQLite or db4o if you prefer a non relational dbms.
Just read the best practices for performance and responsiveness and you'll be alright. Don't worry about performance issues until you find them in your app. You can always optimize later.
Related
I'm playing around with Realm for Android.
I like the auto-updating objects idea, but I have a concern about it regarding software architecture.
I've seen that many proposed architectures specify a layer to handle data/database access, and ideally the higher layers will not know specifics about the database implementation. This will help with maintainability, modularity, etc.
When you use Realm objects, if you want to take advantage of their auto-updating property, the most common way I can think of doing that is having those objects on Activity/Fragment code. Now let's suppose that the user just edited data on screen(that is represented by a realm object under the hood) and is saving these edits. If you call this object's setter, that will actually be a database operation and you will need a transaction. By creating a database transaction on activity/fragment code, architecture falls apart, as you are making your UI/business layers aware of database implementation details.
My question is: how to take advantage of Realm auto-updating objects in a way that doesn't hurt architecture?
Side note: I've used Realm in a recent app and for every query, we had to copy the results to unmanaged objects so that we could send them up to UI/business layers. I don't think that is the best strategy out there, as we could not use Realm to its full potential.
After some research, I came to the conclusion that indeed one needs to make a major choice about integrating Realm to an app: Safe integration x Deep Integration.
Safe Integration
Here you will isolate Realm from the rest of the app code. In order to do that, you won't be able to use the auto-updating/zero-copy of Realm. Instead you will have unmanaged copies, to make sure that anywhere the objects are accessed, you won't have problems with different threads accessing the same objects. Testing is easier this way.
Deep Integration
Here you will use Realm to its full potential, lazily loading data when requested. The downside is that other layers of the code will be aware of Realm, in the sense that they will need to make sure that managed objects are not accessed by different threads. This options potentially involves heavy refactoring if you are not starting a new app, but will bring the performance benefits of the zero-copy approach.
My answer is based on these articles: https://medium.com/#Viraj.Tank/realm-integration-in-android-best-practices-449919d25f2f#.ms3nenq0m and https://medium.com/#Viraj.Tank/deep-integration-of-realm-in-android-production-code-part-2-with-mvp-4cf44ab6289d#.qq4p12mtw
I have seen a lot of NoSQL libraries for mobile platform, but the main thing comes in mind, why we are trying to use NoSQL in mobile systems which are already having very limited space.
Please clarify the scenarios, where they could be beneficial over Sqlite3.
Mobile Application Development (Android, iOS) platforms having complex & rigid structure with relational database. For simplicity of handling of data.As developers come up with new ideas and features for their applications, making changes becomes a time-consuming task because constant changes have to be made to the database schema.
Another issue with mobile applications that NoSQL addresses is the need for constant updates. After an application has been released, maintenance becomes a major concern, among other things to consider. Because NoSQL is document based, fixing certain types of bugs and other problems doesn’t require a complete overhaul of the database, because the changes made by developers don’t necessarily affect every other aspect of the application.
Finally, NoSQL is well known for its scalability. Unlike relational databases, NoSQL databases scale outward rather than vertically. Now a days there are consideration of NoSQL. For More you can read below articles :-
Why NoSQL Trumps Relational Databases for Mobile Applications
Why NoSQL is Better for Mobile Apps
Hope this helps you !
NoSQL is best leveraged for unstructured and semi-structured data, thus, enter mobile application development. I would break down the benefits as such:
Low-Latency Data Storage: NoSQL databases are built to serve predictable, low-latency requests and provide a highly available experience to end users.
Scale for Peak Loads: peer to peer NoSQL databases make it easy to add additional capacity and scale out quickly versus scaling vertically with relational DB's.
Riak (by Basho) is a good one to take a look at.
not all nosql databases need much space, today we have some lightweight solutions, like iBoxDB.net and iBoxDB.java.
and what are the benefits of using nosql, there has a scenario
A database for Q&A and RPG games
I've found that in creating and using a non-sql key/value data store (https://github.com/AaronBratcher/SimpleDB) that I work in a style that uses less memory at runtime. Instead of keeping an array of objects for my long tables, I only keep an array of keys, getting the object values as needed.
I've also found that as I prototype and change the format of my classes, something I've been doing a lot of as the dynamics of my project changes, I don't need to spend as much time refactoring my db layer class because I simply change the class init/value code and spend more time working on more important aspects of my project.
How the app works
Currently an app is in the works which utility is to explore activities in 5 regions. Each activity is represented as an JS object with a fair amount of properties. Activities can be viewed through different filters in their respective tab, for example categories or a map. Inside each main filter, there are options to filter on date, region, accessibility etc.
The challenge
There is a lot of JSON that needs to be stored on the device, and support is required for both iOS and android.
In the best case scenario the data needs to be in sync with the database, and all data needs to be available on the device. The app will need to be snappy for a good experience, this means that fetching data needs to be as fast as possible. Furthermore, filtering data needs to be as snappy as possible.
Viable solutions considered so far (which don't quite cut it yet)
MongloDB with the MongloDB Titanium Store adapter, silver bullet?
This approach at first seemed be the silver bullet. Although the project seems promising, it is maintained by one heroic hacker, and the project is in need of some documentation. I have inspected the source, and hacked my way through the API, but to no avail, console.log and jasmine tests won't cut it this time. More important still, it is not quite finished yet, and features compared to MongoDB are missing. A great project, I hope it will catch on more and be capable enough to assist desperate titanium developers in the future.
JSONDB, only for iOS
This app really needs to work on both platforms, iOS and android, so no reason for trying this. Moreover, JSONDB works within a single context only, which would be a serious concern as well.
Ti Filesystem and JSON.stringify + JSON.parse, not memory efficient
A viable solution for saving a small list of saved items, which is also a feature in the app. But in other posts issues over memory limits with the use of JSON methods have been noticed for android. Though this might not be the least of my problem, memory efficiency overal will be a huge problem. Never have I seen benchmarks for performance with file reading and writing for Titanium, so I am not sure how big of an impact reading and writing would be. Filtering big objects is a huge concern as well, underscore won't manage this kind of big data. Iterating big objects is a huge problem no matter what approach I will choose.
Big ass global object
Practically the same approach as a Filesystem, only keep it in a global. This has the same issues and is just a plain unethical practice.
SQLite, yuck
Highly document oriented JSON data to SQlite, it sounds worse than samsung galaxy fanboys. Any feedback on this?
Multiple files + SQLite to maintain + lazy load, unicorns and rainbows?
Desperate for a solution, I might be onto something in the course of writing this post. There are probably something 10-16 main categories which each 1 to 4 subcategories. Keep all the activities for a subcategory in it's own file, which is a quite slim JSON. Browsing through categories, each subcategory is rendered in it's own TableViewSection, each subcategory be appended independently to the table based on how much the user is scrolled down, effectively lazy loading the content. There is only one quite quick file read. Within this view adding more subfilters effects only the already loaded items, and iterating this items is reasonably affordable.
Updating the data is also quite effective, only files that are subject to change are updated. A SQLite database can maintain the dates of all activities which have a expiry date, it can dynamically build it's own JSON file for the upcoming seven days or month. This will make the calendar view quite smooth for most usage. Picking future dates will be a nightmare though.
Still the map is an issue...
If you have read all of this, thank you. If you have experience with something similar, or might be onto something, feel free to reply! I have to quit writing, quit coding and start sleeping.
Sorry for the crappy monglodb docs. I developed it for some internal projects and really wanted to share it with the community, but the lack of docs does make it hard to use. But great news I have docs now lol also slimmed down and cleaned up the source code. Hope it works better for you now. http://monglodb.com
I'm the original author of JSONDB and thought I'd drop in and provide an answer for anyone finding this question via Googlefu.
JSONDB is now deprecated software - it's been replaced by another project called SculeJS. SculeJS aims to provide a full featured NoSQL database written in pure JavaScript for use in Titanium, NodeJS, and web apps.
JSONDB was originally only available for use in iOS applications due to limitations in the way Ti native modules were built - the current versions of JSONDB and SculeJS are compatible with both iOS and Android apps.
In a lot of ways MongloDB and SculeJS are similar, where they diverge is in the way SculeJS has been engineered. SculeJS is intended more to provide powerful, generic data structures with a rich query layer rather than being a straight port of MongoDB. No insult to Monglo - it looks like great software, I just wanted to point out the difference in intent between the two projects.
As a side note - all pure JavaScript modules are limited to to a single execution context within Titanium applications.
For what you're building I think MongloDB, JSONDB, SculeJS and TaffyDB would all do the job, the details of the implementation would just be slightly different.
I was encountering the same problem. I had about 5mb's of data which I wanted to store with the app, and not let it download.
I finally ended up with an SQLite database, with high performance. It is not as bad as you think. It might not be a nice solution ,but for the lack of choice it is a very good one IMHO.
Just create a couple of tables, and functions to parse them to database, and the other way around, and I promise you, you will be happy.
DO NOT store the JSON in the database, but store the values appropriately.
I'm working on an Android application which is fetching data from internet among other things. Actually, the project was started by someone else which is not here anymore,
and now that I have to turn it into a light client application and implement the server side (in Java), I'm wondering what would be the best tools/patterns to use to fit my needs.
Let's say I have to deal with several models (class representing a category) of objects which all inherits from one class : they have common attributes (such as name, attache thumbnail...) but specific properties too.
Because of this,you can understand that I can't afford to manage one specific table to map each single class.
However, I still want to be able to cache my objects somewhere in the Android device to populate the views of the application when working in offline mode.
Currently, the solution used by the previous developer was to store data directly into a TEXT field in the SQLIite database, as serialized objets.
This should be ok on the server side but I've read that the usual Java serializaton was very slow on the Android platform, although it is not really noticeable now because I work with around ~50 objects, I was looking for more performant alternatives for the future.
I've came across the JSON solution which can easily handle complex structures and Jackson library seems very interesting with its simplified data binding to POJO objects and its well-known performance.
But then, how should I store my Json objects ?
Is it possible to keep a json string in a TEXT field of a SQlite table ?
Or should I rather store them as .json file for each object ?
Which one is the more efficient to retrieve later lot of data?
Plus, I was thinking that JSON would be a very good exchange format between the Android client application and my server whould is in charge of processing the information from internet third-parties apis and exposing this data with webservices. (rather than trying to implement some RMI-like solution)
Is using the usual Apache HTTPClient enough on Android to communicate with the server?
For those who successfully developped client-server application (which seems very common to me) is this a good approach for Android ?
It seems to me that with mobile platforms, you can't really use the approach that you've learned for more classic J2EE app and such...
Any advice would be greatly appreciated because I'm a student and Android beginner who really want to improve her mobile development skills !
Thanks :)
That's open to discussion, so SO is probably not the best place to ask. In general, before declaring something is too slow (or fast), measure, compare and pick the one that works best for you. Yes, you can save JSON in a DB, an it will generally be faster than having separate files on the FS. But, again, benchmark and compare.
BTW, most J2EE 'approaches' (patterns) are overkill for any platform, let alone mobile.
I am developing android apps, yet I used shared-pref and JSON(rest web service) for storing data. I generally tend to prefer less sophisticated technologies, as I believe more complexity results in more issues. But for my new app, it may be better to have db-like storage.
What do you think about using SQLite in Android , is it really light? Have you experienced performance or compatibility issues developing SQLite for Android?
Namely would you recommend SQLite over simpler alternatives as android storage solution?
Thanks
SQLite is light, fast and it works.
It all depends on what data you want to save. If it is good to have a real database with relationships for your new app, then don't be afraid and go into SQLite.