I want to make an android app that have two sites, one is for customer and the other one is for driver and operator. I'm a little confused how to do this. I thought I would make two projects but have one database.
How do I do this? Or is there a better way? Please forgive this stupid question. I'm still learning btw.
There is NO hard rule.
Largely depends on why or why not?
Architectural Patterns and Design Patterns are not meant for avoiding duplication or tight-coupling. They are not rules. These are very matured well tried and well tested convenience patterns.
Many times there will be redundancy or tight-coupling by policy or by business rule or legislation or efficiencies or to avoid maintenance complexity.
To answer your question…
E.g. You require an application which has large data input say to 10–50 Lakh records per 24 hours. These records need to be processed and reports updated ASAP before the end of Calendar day which is 12 midnight.
It makes sense to have the two different projects with a common database:
Which processes the data and generates reports in the background even possibly based on a scheduler
A UI based application which allows users to input data and view reports.
Something like an email or sms campaign.
In this case both projects will be accessing the same database or databases. You may have master data on an RDBMS server and trasactional data on NoSQL database for analytics and reports etc.
In QA or at the end of delivery you will anyways know what went right or wrong with your architecture and design.
You may want to discuss these things with your applications architect. Have a good academic relation with your applications and solutions architect. It will give you great insights.
Related
I want to develop a Nutrition Recommender Smart Phone App. Details of project are following.
This app will:
•
guide patients about the choices of food and diet plan according to
their health issues.
provide a list of dieting plans
recommend healthy food choices for men, women, toddlers, kids etc.
according to their age, weight and health condition
• have the calorie calculator
have some good articles about diet and foods
inform people about the nutrition importance of different
vegetables, fruits, beverages, grains, oils, dairy etc.
share some innovative ideas about breakfast, lunch and dinner.
But I don’t know how to design database to implement above functionality. Can someone guide me how many tables should I create and what tables relationship exist?.
Introduction
First of all, this is very basic what you wrote us. You should start specifiing those things and get more into details. For example for a diet plan you can think about the properties such plan could have. Properties are e.g. the length of the plan, the nutrition you need and maybe some sport-excercises. Just some samples. Then you may split up the nutrition in one table and so on. Now you can think about if you want to do all the database stuff on your own, or use a framework. Actually the whole database stuff seen in MySQL and so on is done on a webserver, because of security leaks on the client (decompiling, traffic reading, ...). If you want to save data on the local storage or in a local db (SQLite would be you choice) then you should also think about if you want to use an API for that (e.g. RoomAPI by Android Jetpack)
General thing
You should get your self a clear mind which architecture you want to use. You can store data on a webserver and transfer the data via web-interfaces e.g. REST with JSON or XML. You can also store data on the local device in a file or in a database (which is basically also a file with specific interface requirements). You have to decide and consider you require the exchange on multiple devices or just for one device on it's own.
Planning your structures
After you know which architecture you want to use, you can start planning. First of all I would suggest you to get an abstract view of your project. That means just writing down what you want to have and then start writing down the corresponding properties. For a diet-plan this may be the name of the plan, the length, required nutrition and so on... After that you may know, oh okay, I also need a table with the food and you will see (automatically) that there will be a connection. If you see the connection just draw a line connecting those. In an ideal situation you already know the relation of this connection (One to many, Many to one, Many to Many, One to One, see this stackoverflow article: Difference Between One-to-Many, Many-to-One and Many-to-Many?).
Implementing your structures
Anything I do is handcrafted
In the case you want to do all on your own you may use a gui tool for databases to design your database. You can also use commands to do that, what need much more effort. You can decide on your own and on your knowledge.
Pro for gui
Easy to use
Fast creation of the tables
Contra for gui
May use some cryptic names for indexes and keys
"May don't let you look behind the scenes"
I rely on APIs
You can also rely on APIs. That means often, that you can program the class according to your plan, then annotate it and the connections/relations would be managed by the api. Such abstraction-layer is Room for Android or Doctrine for PHP, those are just samples and there are much more.
Conclusion
How you get the data into the database and out of the database is your thing. You could rely on easy use of APIs or get your things done by yourself. It should be a little guide for you to understand database design.
P.S.: If someone has things to edit, do that! I would appreciate that!
Cheers Tarik.
My goal is to collect health and family related data through interview some patients. So I'll provide every information about every view or question in database. like view type (radio button,edit text ,spinner...), data type (text or number), data length, whether it has any media (image, audio, video) regarding this question. Questions might have a dependency (visibility or value) on other question. I have tried so far and what I got that for small number of questions its okay. But when its about 100 or 150 or more questions, performance is not good. Since I am running lots of sql query and refreshing view manually. I mean on event (onSelect, onChange, onChecked.....) I am saving data to db, changing other question's visibility, value. So far lots of requirement have been added to my app. Can you suggest me about coding structure , library so that I can improve the performance? What are the things that should be used in this app? I have attached some pictures so that you can get a idea.
View Demo https://i.stack.imgur.com/ZCGuz.png
Dependency https://i.stack.imgur.com/j2nzj.png
Required field validation https://i.stack.imgur.com/tFuOH.png
You could use Google Firebase services. There are some huge advantages compared to sql especially with app development. It's optimized for many queries and therefore it's speed is impressive. You can just a Firebase account and use it(Although with limited resources). I would really that you add the firebase library to your project. Also with sensible health and personal data should stay private and as far as I know there are literally always security issues with Apache2 or nginx or php or mysql/mariadb so just do it the easy more reliable and more secure way. I hope I helped you out. :)
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 am making a dictionary kind of an app which uses SQLite. I have a single table that keeps the pair of foreign words and their translations. I want to sync this table with a particular spreadsheet in Google Docs.
I ve found this awesome library to retrieve and manipulate GoogleSpreadsheets, so at least I am covered for that. But I donT feel comfortable about the sync. Now,
Can I use a SyncAdapter to do this sync between my SQLite and a GoogleSpreadsheet? If yes, how would I go about it? Would I retrieve and manipulate the rows of the spreadsheet in the onPerformSync or smth?
What could be the other alternatives for such a scenario? Should I maybe use a normal service to do the check when the user requests it (in the main activity, for example) ?
On the Google I/O vids (particularly on Android REST client apps ) they seem pretty persuasive for using the SyncAdapter but I am not sure if it could help me without an actual REST service.
Thanks in advance..
One good reason to use the Android SyncAdapter, ContentProvider and SyncManager is that you will benefit from the Google system knowledge that is useful for preserving battery life and other resources. Some of this content is in the video you link to. For example, exponential back-off logic to prevent wasteful attempts at synchronizing.
There is some good info about battery life preservation by conserving cell radio power in today's Google I/O 2012 talk "Making Good Apps Great: More Advanced Topics for Expert Android Developers." While not mentioned explicitly, I think that the SyncManager is likely to have the battery conserving properties that are mentioned in this video.
Based on my reading (not actually implementing anything) of the APIs and other resources such as the com.example.android.samplesync package, it seems that the pattern is flexible enough to adapt to your program needs.
The team I'm working with has implemented custom sync for our android app but I can tell you we didn't consider this option because we were committed to writing as much logic as possible to run with the WebView. I wouldn't necessarily recommend that, but that's beyond the scope here.
First time posting and first time working on Android, so go easy if I am breaking any rules :)
Anyways, I just got into making an Android app and I'm trying to create a simple trivia game. I plan to have many questions (hopefully about 5000+ questions) made. No data manipulation made, just straight up reading the questions and presenting it to the user. I am now faced with the dilema in how to store the questions.
I have two choices:
1.) Bundle the questions with the app: Possibly store the information in SQLite. Originally, for demo purposes, I placed the questions in an XML file, but I quickly realized how inefficient it will be once the questions start piling up. First, I am concerned if opening up such a huge XML file would suck up Android's memory. Secondly, I am worried how large the app would be if it contains 5000+ questions. I read here about the pros of XML vs SQLite. In that example, the user has 70,000 entries so maybe my 5,000 questions would be enough?
OR
2.) Host the questions on a server: I believe the upside is the app wouldn't need to be bundled with a vast amount of questions and wouldn't need to worry about the logic of opening and assembling the questions. It would just hit a PHP page and depending on the parameters sent, the PHP page would return the questions in XML format. The downside is the user would need to be online (to retrieve the questions) in order to play the game and my server would need to be up and running 24/7.
Has anyone encountered this design issue of how and where to store vast amount of data in an Android app?
Thanks, any help would be much appreciated!
From a marketing perspective, I think the right approach is #1. Just looking at the top app list, it's filled with apps that work offline. I don't know why most people fail to mention this one important criteria when they talk about marketing apps... especially in Android, where lots of people don't have a data plan. Plus, a trivia app sounds like something someone would probably use during a commute in a train as opposed to something like Facebook Chat that they'd use when they're online.
From a technical perspective, storing 5000+ questions really won't take a huge amount of space. There's this app called "MyFitnessPal". It stores maybe over 30,000 foods in a SQlite database, with nutritional information. So don't overestimate how much space it will take.
The advantage of going with #2 is if the questions or answers change often, you might want to go with that approach.
I think that the best option for you is to store the questions in SQLite.This way the users can have access to your game even if they are offline,which is one of the important things as Hisoka mentioned. So I think you should try using SQLite.