Coming from Java EE to an Android application (i'm not Guru in Java EE), For a fatest load of the application, we decided to process a files asynchronously, when the application starts, we launch some asynchronous channels to read the files, then we open the main activity, the idea is the user may not go directly to the use cases which need these files, but if he go it direclty and the asynchronous read wasn't terminated, he should wait a while(what the client wanted).
My question is how to passe the Future object between activities? my team agreed for using static methods or singletons, but i really don't love singleton because its an antipattern and i don't like static methods because they behave nearly like singleton.
Trying to use parceable or serializable, but future doesn't use implement anyone of it, i tried to use RoboGuice (its based on static fields but its busniss) but its a little buggy, how can i do it in android in pretty way, if there's another idea, i will be obliged to use singleton or static methods.
EventBus can be used to send objects from 1 place to another (e.g. asyncTask to Activity). It's great and easy to use, and it will accomplish what you're trying to do perfectly.
You can create your custom object classes to send between almost any 2 classes, Activities, Services, or whatever you with.
Related
While the core manual (and other documentation) of Vert.x shows several use cases and gives good explanations of Vert.x in general, I am curious what are do and donts when designing verticle classes.
Preword: I am aware of that the design of Vert.x is in general AGAINST giving strict design guidelines. So, no need to mention this in answers.
An example that led me to this question is as following. I created a verticle named ServiceDiscoveryVerticle.java which has the following responsibilities:
read in a configuration file of services and then publish them via the Vert.x ServiceDiscovery
manage services additionaly in lists(published/unpublished) to keep track of unpublished ones
receive messages via the event bus, for either publishing or unpublishing a certain service
All this is code is manifested in the overriden start method.
So the core questions I ask in this questions are:
What are do and donts when designing verticle classes ? (by your personal prefence/opinion)
Are there any general guidelines of what belong to a verticle and what not ? (officialy or community-wise)
Is it recommandable to split the start method up into private methods (if so, should it be in the same class or better put in a seperate one like OwnServiceDiscovery.java) ?
Any other ideas/remarks on my given example(ServiceDiscoveryVerticle.java) ?
One can do a lot of philosophy here, but I will try to keep it simple.
The fact is that a verticle and its start() is and will be the main way that you init your system, mount handlers, trigger things like loading config and co. So don't be too hard on yourself, this part is correct.
If you are using Web Service API or Service Proxy then handlers are mounted automatically for you. The actual code of these handlers are in external classes that you can decide on how to structure them.
If you are mounting your handlers on your own, then you can use a lot of inline code, or you can decide to extract them into classes. In a lager application however you will probably split and extract code as much as you can.
I personally extract code out of verticle as much as I can and make it a rather coordination and setup place. Also my start() method (or rather rxStart()) is a bunch of calls to other methods who's names give me an overview of what is going on in the start of system rather than having a lot of code that I can't read. But these are all personal preferences as you said. Vert.x does not imply any of it on you!
Don't block the Event Loop
Don't call verticle from another verticle, use EventBus
If you're using executeBlocking, you're probably doing something wrong
If you're constantly deploying/undeploying verticles, you're probably doing something wrong
Don't share state using verticles
Keep your verticles small, but not too small
In a java project i need to call (lets say generic, utility) web services. For instance giving a city code as parameter and getting details about that city. Web services are already implemented and i can only consume them.
I had the same situation before in another project and created a class for that kind of webservices. That class had several web service call methods and all were static methods.
Now, i dont really want to do same thing again because i dont think thats the right way to do it (hard to debug etc). I also dont want to make a different class for all these methods and make an instance for each call because they are too generic and instantiation seems like an overhead for that situation.
So, alternatives comes to my mind is
Using old method. One static class, several methods.
Singleton class. Most probably will have syncronisation problems, so will have overhead using locking mechanisms.
Both are not the best solutions what would you suggest?
Thanks in advance.
I'm writing an Android app that has some functionality encapsulated in an internal library. However, for this functionality to work, the library needs an instance of the Application Context. What's the best way to give the library this Context? I see a few options, none of them appealing:
Have my library classes extend Application, and call getApplicationContext()
This is generally discouraged
Have my library classes each implement the singleton pattern, and have each caller pass in a Context each time they get a reference to the singleton.
This requires every caller to retrieve the Application Context before using the library, and also requires that the caller call against an instance of the library instead of against static methods defined on the library class (and thus further requires keeping a reference to this instance).
What's the best way to give the library this Context?
Pass a Context into the methods exposed by your library that need a Context. This is what the Android SDK does in places.
Or, change your library to expose objects, not static methods, and have the objects hold an instance of Context (supplied to the constructor or factory method that created the instance).
Have my library classes extend Application, and call getApplicationContext()
If you can call getApplicationContext() on a Context, you would just do that, without needing to subclass Application.
This is a solution that I found, which I have not tested, but is used by Firebase apparently to avoid creating an init method:
"What happens on Application start is, that it registers all ContentProviders in the system (calling onCreate). This means that at this point no activity has been started, but we have access to the (Application)Context, where we can initialise our library using this Context"
Essentially you are utilizing the onCreate of the empty ContentProvider as the init. It is hacky, but seamless.
https://medium.com/#andretietz/auto-initialize-your-android-library-2349daf06920
I am not sure best practice for this case but i would like to set the Context in my singleton class during Application onCreate.
MyLibrary.init(this);
Why?
If you had use Crashlytic/Fabric before, you will found that they are using
Fabric.with(this, new Crashlytics());
If you read the code in Fabric will found that they store the Context in Fabric singleton.
Facebook Android SDK did similar thing:
FacebookSdk.sdkInitialize(getApplicationContext());
If your browse their codes will found that they store static Context.
Well, which are the best practices? I am not sure but i believe those are awesome developers create awesome libraries and they did debate on this before come out this libraries. Anyway, I am still learning how to write best android library and come across this topics.
App Startup library is the part of Android Jetpack. It allows to listen application startup without the cost of multiple ContentProviders. Also, it provides the ability to handle dependencies tree.
Implementation example
Converting an existing Android application to a library is incredibly simple: All I have to do is check the is Library checkbox in the project's properties.
However, once this easy step has been applied, a much more serious task lies ahead: How to retain the original application code unchanged (as a library!), while building different applications based on it.
That is, I don't really want to add another activity, but rather re-use the original activity (now in a library), where only a few methods (in the one-and-only activity) are different in each derived application.
Is the solution really is as simple as subclassing the library's activity in each application based on it?
What caveats should I watch for?
Is there a better approach?
You will mostly have to derive new classes from the ones included in the librairy or call their methods. If your librairy has classes such as activities, applications, you can extends them has you said.
Another solution could be to isolate the code you want to reuse and plugit into other activities by dependency injection. But this framework seems an overkill to me where you can just derive new classes.
A more android specific problem could be : how to call my new activities from within my new applications. The answer here relies in intent and to use different action names to call for the extended activities.
Regards,
Stéphane
Since the whole Android stuff is open source I was thinking about to do some minor modifications in a few internal classes from the com.android.internal.telephony package and of course then I would love if somehow my application could use the modified classes. I was thinking about replacing the classes with the original ones at runtime by using reflection or other kind of unknown java tricks :D ...maybe what I'm trying to do is impossible :( I don't know that's why I'm asking.
Note: The changes in the internal classes would not change their functionality in any way, its more about extending their functionality so even if other apps would use the modified versions it would not break them!
Why I want to do it? What I'm trying to achieve ?
Well i would like to modify the com.android.internal.telephony.gsm.CallTracker internal class so i could do proper call handling (call blocking etc..)
Maybe if you know about another way how to do what I want to I would like to hear about it :)
Note2: I know about the method when you handle the android.intent.action.PHONE_STATE, action , but its simply too late to react when this action is broadcasted. I'm really looking for a better solution even if that solution involve ugly hacks :)
As always thanks for all your replies...
You cannot do this :) I'll let you imagine what would happen if any application was allowed to freely replace core parts of the system. You can download the Android source code and you can modify it and you can upload the modifications to your phone (if your phone is rooted/unlocked) but you cannot apply such modifications with a simple app.
Changing a classes functionality (methods, byte code) after a class ha been loaded is impossible. Reflection/Invocation does not affect classes but static fields and instances only.
Your looking at a way to add additional methods or change existing methods of a running system, because the classes in question probably will be loaded already when your 'hacking' application is executed.
The only technical approach that I see is to change the classes in advance and deploy a modified system. I'm just ignoring possible licensing issues and security at the moment. But even with this way, your software would depend on a custom OS, a branch from some andorid version, disconnected from official updates, and you'd have to ask your customers to install a custom OS with, say, unknown features.
Sidenote - I'm very happy, that this is really impossible, otherwise my mobile would already be full of trojans, viruses, etc...
Romain is correct you can't and shouldn't try to change existing system classes.
That said, implementing call screening as you suggest should be possible by creating a replacement to the dialer application that handles phone calls.
Specifically the intent ACTION_ANSWER should be handled by your application, which could then either implement a dialer-like interface or open the dialer app (or any other call manager) explicitly.
There are actually ways to hack on Android framework classes, it just depends on which ones you want to hack.
You must extend the class you intent to hack on.
If you want to override package private methods and/or access package private variables you can put your class in the same package.
You can use reflection.
I've actually had to do this to work around bugs. Romain is correct, to an extent. It all depends on the structure of the code you are trying to hack on. You definitely can't hack on Android internals, but you can hack on other framework classes like Activity, View, etc.