Develop Reference

Network module on a multi-module project android

I'm trying to implement this multi-module design on my app, the thing is that I'm thinking about create an "api" or "network" module where I create the retrofit instance (I'm using Dagger2, but it doesn't matter, if you have an example or pseudo with any other DI framework feel free).
Problem?
I've been working on an app that I had this similar architecture but it ended up with a big module because I had organised the instance of a retrofit and then inside of it a sub-packages with each feature where I have the services and the responses.
This helped me with a problem that I had for instance, use the same service on a different features.
Example
Home feature I need to call the Feature1Service to show X
Feature1 need to call Feature1Service to show more stuff
I've thought with a solution that instead of creating the api or network module create every service inside of that feature, but doing this is a problem.
So I'd like to listen options or if you have worked with that app with modules how did you do that?
Short question
How do you use on multi-module project where you share services between features? (Retrofit)

What is the definition of Android Native Code?

I always see the term android native code here and there but not sure what exactly it is. So which part of android is android native code? Are Application, Activity, Fragment, View, Looper android native code?
More context: I'm trying to understand the shadow in robolectric tests, and in the doc it is said that "Android native code cannot execute on your development machine", so I'm wondering are classes like Application, Activity etc android native code referred here?
http://robolectric.org/extending/

The word native in Android development is overloaded.
Going through link you provided for Robolectric:
There are limitations however:
Native code - Android native code cannot execute on your development machine.
Out of process calls - There are no Android system services running on your development machine.
Inadequate testing APIs - Android includes next to no APIs suitable for testing
Roboletric fills these gaps with a set of classes known as Shadows...
So in this case the Android native code quote either refers to:
The Android Framework classes like Activity,Fragment,View where with only the Android SDK apps needs an emulator or device to run. But Roboletric bring its own Android Framework code which can be 'enhanced' by 'Shadows' for testing apps.
OR
The Android Native Development Kit (NDK) which uses Java Native Interface (JNI) to allow Java/Kotlin code to access C/C++ code for performance or compatibility reasons. So with Roboletric you can't call into JNI code, or at least not without some effort.
Later that same page:
Using byte code instrumentation Robolectric is able to weave in cross platform fake implementations to substitute for native code and add additional APIs to make testing possible.
The substitute for native code refers to Java/Kotlin APIs belonging to the Android Framework which Roboletric is substituting for to provide a test environment. Again, those would be the Activity, Fragment, View, etc. you were referring to.
The usage of the term 'native' in this case is similar a developer using a third-party app building framework like 'React Native', 'Ionic', 'Flutter', 'Xamarian', or 'Cordova/Phonegap', they may use a custom component written in Java/Kotlin as a native component to achieve some function which can only be done by direct interaction with the Android Framework but not in the language/API of that third-party framework like Javascript, Dart, or C#.
Java and its kin (Kotlin, Scala, etc.) refers to calling C/C++ code as native via the Java Native Interface (JNI) and on Android is facilitated by the Native Development Kit (NDK). Third party app development frameworks that sit on top of the mobile framework will refer to calls into the original mobile framework as "native".
Sadly as this is part of the terminology used in mobile development so a careful reading of the use of the word "native" is required.
Personally I would prefer if documentation using the word native included the language like native Java/Kotlin APIs or native C/C++ APIs as the first instance in the linked page had me going back and forth about the author's meaning.
Follow up to questions in comments
You mentioned that "they may use a custom component written in Java/Kotlin as a native component", you are referring to Activity, Fragment etc when saying custom component, right?
In that particular section I was referring to third-party app frameworks calling into classes that are Android Framework or directly call parts of it. Normally those third-party app frameworks already wrap/expose Activity, View, etc. but you as a developer may need a library or other custom Java/Kotlin code which can be invoked by the third-party app framework language (Javascript, Dart, C#). From the perspective of the third party app framework the 'wrapped Java/Kotlin library' is a native component as it is "native" to the mobile environment. That wrapped library code isn't written in Javascript, Dart or C#. Again the meaning of "native" is overloaded.
In the first paragraph of link, the author is emphasizing that we will run "real Android code" in robolectric. But as we analyzed, robolectric is shadowing the basic building block like Activity, Fragment, which seems contradictory to me, so the only explanation I can think of is that the ShadowActivity is wrapping the original implementation of real Activity, do you think that is the case?
Yes, the ShadowActivity is "wrapping" the original implementation of real Activity, I would take note that the author states: Shadow objects are not quite Proxies, not quite Fakes, not quite Mocks or Stubs.
It is important that shadow methods are implemented on the corresponding shadow of the class in which they were originally defined. Otherwise Robolectric’s lookup mechanism will not find them (even if they have been declared on a shadow subclass.)
and
Shadow class inheritance hierarchy does not always mirror that of their associated Android classes, it is sometimes necessary to make calls through these real objects so that the Robolectric runtime will have the opportunity to route them to the correct Shadow class based on the actual class of the object
So regular Java inheritance isn't quite the correct mental model for Shadows.

Android native code is not Java or Kotlin. It is not some classes like Activity or Fragment. Android native code is C/C++. Here is a bit of info about SDK(NDK).
And here you can find general overview of NDK(native development kit).
Hope it helps.

Android Dagger 2.11 and Retrofit dynamic URLs

I’m working on a project that is based on the GithubBrowserSample demo application that’s on the Android Architecture Repo on Github.
So far, I was able to inject dependencies to my App, activities and fragments and ViewModels. Also I was able to add more Modules; right now I use two, one for Shared preference and the other a NetModule that has all the mumbo jumbo related to Retrofit/OkHttp.
But here’s the catch: currently the demos that I found that shows how to implement the Retrofit/OkHttp module has a static base URL, which doesn’t work for me since that information is available until the User provide it on the Login section…
Digging around I found that one solution is to create a Submodule (StackOverflow post) with a given Scope Instantiate the component inside my Activity/Fragment. But because I’m using Dagger 2.11 for Android to perform the injection, I have no idea how to do so…
Is there an example that I can look around, or should I give up on this path and take the OkHttp interceptor to change the URL?
Thanks in advance.

Dependency injection for Android NDK?

I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?

If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)

Mocking framework for use with xamarin android

I am trying to find a mocking framework that works with Xamarin Android. So far I have tried Rhino Mocks and Moq but both depend on System.Web.dll which does not seem to be supported by Xamarin. I have included the System.Web.Services reference to my project with no luck.
So my question is what mocking frameworks out there are compatible with Xamarin projects? This is just for simple mocking not even specific android classes like activities, although one that could combine both would be best.

From what I've observed, there really is no mocking frameworks that work well with Xamarin. On the iOS side, this is mainly due to the inability to use Reflection.Emit because of the code generation restriction imposed by Apple. I realize you're on Android, so that restriction does not apply to you. However, other restrictions arise, like you've found with RhinoMocks. My favorite mocking framework is Moq, but I can't use it with Xamarin because of some of the configuration namespaces that are implemented in .NET, but not in Mono.
So, your best bet is just manual mocks. I know that's not the answer you want to hear, but it seems to be the consensus.

You can use True Fakes (http://truefakes.net) mocking framework to solve your issues. It doesn’t use Reflection.Emit at runtime, but it automatically generates mocks at compile time and add it to assembly where unit-tests are. This allows you to use True Fakes for writing unit tests with fully isolated system under test for Xamarin.Android and Xamarin.iOS and running them directly on the device!
You can add it to your project via NuGet (https://www.nuget.org/packages/TrueFakes/).
Please see more information about True Fakes at http://truefakes.net.
PS. I’m developer of True Fakes mocking framework.

I've been using a mock generator called PCLMock.
I had to fork it to get it working with .netstandard, you can give it a go by cloning it and building it from here:
https://github.com/pellet/PCLMock
It works by generating code before compile time, therefore not needing the reflection apis missing in AOT compiled xamarin projects.
Otherwise you could always go functional style and pass in your dependencies as delegates/Funcs, this way you don't need to generate mocks for interfaces, you can use a builder class for injecting mocked out lambdas in unit tests.