I'm currently developing an Android application and I'd like to have an scalable architecture with a clean separation of concerns. The requirements of this application are, mainly:
User autentication (I'm dealing now with Google Sign-In for Android after many unsuccessful fights agains Android Identity Toolkit)
Synchronization with REST services (this application should be collaborative, I've already done a proof of concept to consume a "heartbeat" service, using AsyncService, that was the only way I've found to clean activies code, I got to that library researching about Robust Android Architectures)
ORM at client side to store user generated data and retrieved data in the future (my choice has been ORMLite for Android)
Material Design (as the best approach to the UI I have in mind)
First of all I'd like advices on how to separate classes inside the project, I mean, should I use folders (activity, model, DAL, service, sync...) or should I create my own libraries? (in .Net I'd create libraries with parent namespace)
My second and biggest concern is about user identity: how should looks like my architecture to achieve my goals? (sign up / Sign in with multiple providers, authenticated rest client and synchronization using SyncAdapter)
I hope you don bane this quiestion because maybe is too generic but I ask about all this stuff because I couldn't find information or advices about this stuff.
Thank you in advance.
This is a generic question and every dev has his own way to achieve this, but I would recommend to follow one of the trending patterns right now.
There is a project call the clean architecture. It has pretty much everything from dB to Api. In my opinion is a over-engineered.
I prefer another pattern called Flux.
Together with retrofit, eventbus or Otto makes building apps easy and keep the structure
You can read more about it here:
http://lgvalle.xyz/2015/08/04/flux-architecture/
Related
I want to develop a real-time chat application in Android like WhatsApp or telegram
for the all-purpose client should connect to the server via WebSockets and even
offline or online has to works fine. I decided to use Android architecture like MVP, MVVM, and MVI, but I'm confusing which one is suitable for my app
Can anyone help me to choose one of them?
And my second question: is it ok to use WebSockets for all APIs or it should better use WebSockets and REST APIs together?
Thanks for your help
There are quite a few patterns out there for app architectures. The most well known are the classic three-tier architectures such as:
MVC: Model-View-Controller.
MVP: Model-View-Presenter.
MVVM: Model-View-ViewModel.
All these patterns represent the main similar idea — to structure your project’s code in a way that it is separated by the different generic layers. Every layer has its own responsibility. That’s why your project becomes modular: separated code parts are more testable, and your app is flexible enough for continuous changes.
MVP is strongly recommended because a lot of developers are using it now. Even, Google also provides its best practice example on Github. You can see full document here.
I strongly recommend you use MVVM because Google has adopted this approach for Android Projects recently. You can find a lot of examples about it. Especially LiveData and ViewModel mechanisms have a lot of advantages in terms of separation of concerns and managing the relations between ui and data.
Is there any in-memory implementation for Firebase database for testing Android client logic and integration? I have seen node.js fakes but could not find anything in java. I am not looking for a plain mock which is only good for basic unit-testing.
You must do refactoring your application, and implement an architectural approach. For example, such as MVP, MVVM, Clean, etc. The main thing is the layers. In this case, you can test these layers independently of each other using mock objects.
On the Internet you will find a lot of documentation on this topic,
eg Essential Guide For Designing Your Android App Architecture,
Why to choose MVVM over MVP — Android Architecture and many others.
I have started working on a university project. I have to test various REST frameworks for Android and see which one is the most efficient/stable currently.
Which are most popular REST frameworks currently for Android? I have heard about Spring.
Secondly, how do you create a RESTful service for Android?
There a number of REST libraries that do more or less for you. Arguably, the most popular for Android are Retrofit (https://github.com/square/retrofit) and my personal favourite RoboSpice (https://github.com/stephanenicolas/robospice) for two simple reasons: runs as a service and works alongside Activity lifecycle.
Answering which one is the best would start a flame war.
Keep in mind that ANY library that can do a HTTP request with POST and GET can be "weaponised" as RESTful library, it's only a matter of how much boilerplate you want to write on your own and how much control over each aspect you require.
Disclaimer. I'm asking this on someone else's behalf and given that I know as much about Android development as penguins about flight, it may be clumsy. In such case, let me know and I'll remove it or try to reformulate.
I've created a web service that's reachable at the URL on the following form.
http://server/Blopp.svc/Store/value1/value2
The back-end part I've got covered but I'm worried about the front-end development. I've got a colleague that's making the app and he's got the rudimentary GUI done. However, in order not to do a lot of convoluted coding, he's heard that there's a certain library for making such URL calls.
What's the name of it? Is there certain other aspects to take into consideration or is there an (almost) standard one that everybody uses?
Please not that the app's functionality is at the moment limited to providing the web service with data. All the logic and presentation is done on the website and not inside the app.
I've never built up an Android app, so I'm asking for understanding if this is a dumb formulation. I just want to help my co-worker and he seemed to struggle with the details.
Is there perhaps a smoother way to make the call to a web service if I substitute the patter of the URL to use query strings? Any other approach that makes it easier for an Android developer? I'm not familiar with the area but I want to make things easy for my team-mate.
There are quite a few different HTTP libraries available and it would really depend on your specific requirements which one you used (if any - you can roll your own HTTP requests using HttpURLConnection) Two of the more popular ones are:
Volley
http://developer.android.com/training/volley/index.html
Written by one of the guys on the Google Play team and part of the AOSP. Very flexible and easy to use however I would hesitate to recommend it as it relies on the now deprecated Apache Http classes in its public API.
Retrofit
http://square.github.io/retrofit/
From Square. Version 2 is currently in late stages of beta. It allows you to define your API as an interface. It has dependancies on their OkHttp library as well. Very fast and also has RxJava support baked in.
I am relatively new to app development and core data, so take it easy on me. I have been working on an app (currently for iOS, android in the future too) which stores the user's data locally using core data.
The data has relationships across entities. User can create, update, delete data.
Now I need to integrate some kind of syncing solution. My requirements are:
Data should be accessible offline (right now I am testing queue operations for that)
Data should sync to cloud storage when network is available (on iOS I have tested out reachability for this)
Cloud storage needs to be integrateble to both my current iOS and future android version.
Relationships (or some other way of linking parent-child, i talk about it later) need to be maintained.
Core data on ios should be used, not third party replacement.
I have messed around with many solutions so far:
I setup my own rethinkdb database on a server and used PHP and REST to get things going. This was very messy.
I tested parse.com and afnetworking http requests (instead of parse's library) - this was better, but i couldn't seem to be able to manage the relationships from core data. And my syncing algorithm is complicated (it works but I am not sure if there are holes in it when it may fail)
I tested dropbox datastore api. I have only tested the iOS sample app they provide, seemed pretty good (still need to understand the workings).
My questions are:
If I were to use dropbox datastore api, how does it work with android? of course core data is not available there, so how does that work (sorry I don't have android dev experience yet)? ALso how does it handle relationships between entities?
If I go with Parse.com, do you think my this idea will work-
Instead of using relationships, I can use identifiers? my relationships are all 1-to-many, so on the parent (1) I can have an id A. On all the children I can point their parentid to A. Also since my children can have grandchildren too, on each of the children I can have another id which the grandchildren can point to. So on... does this make sense as a replacement of relationships? If yes, then what's the point of relationships in xcode?? other than having automatic cascade option maybe.
Are there any better solutions available for syncing cross platform?
I know my question may seem a bit asking for opinion, but I would like to see what everyone else has already tried. Past week of switching from one solution to another and designing the syncing algorithm has fried my brain.
(I work at Dropbox and will address just that part of the question.)
The Dropbox Datastore API doesn't use core data and thus works exactly the same way on Android. Why is core data a requirement?
As to relationships, what you describe for Parse is exactly what I would suggest for use with the Datastore API. I believe you're right that the reason for modeling relationships in databases and in code is to get automatic cascading operations and enforcement of relationship invariants.