Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I know that Dagger is a dependency injection framework, but I have not still used it in my projects.
I am starting a new project and wondering if Dagger is suitable for it. As far as I understand, using of Dagger leads to a lot of boilerplate code and annotations.
So I am not sure if it is not an overkill for my relatively simple project.
A bit about the project. It is focused on image processing and main part of functionality is built around it. However, it will also probably have a simple backend for data storage.
In general, I would like to know some basic principles that I can use to choose using Dagger for a project or not.
Basic Understanding:
Suppose, you want to test your application that deals with Credit Card service. For testing purpose you must not want to Access a real RPCCreditCardService as it will need real transaction and other stuffs that you don't want to perform during development. In that case you must had to create a clone fake service that will mimic the same thing that real CreditCardService does but not transact anything. If you use the dependency injection framework you can define common tasks in a dependency and inject it in both fake and real service. It will minimize coding complexity as well as helps to make each module independent.
From the documentation:
By using dependency injection framework, each class is easy to test. You don't need a bunch of boilerplate just to swap the RpcCreditCardService out for a FakeCreditCardService.
Dependency injection isn't just for testing. It also makes it easy to create reusable, interchangeable modules. You can share the same AuthenticationModule across all of your apps. And you can run DevLoggingModule during development and ProdLoggingModule in production to get the right behavior in each situation.
Reference:
For more detailed understanding you can check this discussion.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I develop an app for both iOS and Android, and I'm loon'ing for the best way to share code between this two platforms.
What I would like to do is creating all the View (UI part) in native but share the code for the logic (controller + model).
With all I found, 3 things seems to be quite good :
1) C++ --> Build library file Using c++ For the logic so I'll be able To use the .dll files in the 2 platforms
2) Azure mobile apps services. Is it possible to habe all the logic in a webservice? The issue is that if I dont have acces to internet, my app will be unaivalable, right?
3) I hear a lot about React native used by Facebook, but it seems to be used to create the UI, but I prever create it in native. Can I use react only for logic?
It seems like you have three options:
1. C++
You can't just have a compiled .dll and expect it to work for iOS and Android. They both have to be compiled in different architectures and it has to be a static library on iOS.
Dropbox's done it this way, and they've put up a lot of notes and example code, and code you can use so you can take a look.
Pros
• Pretty straightforward after you manage to set it up
• No additional layer of dependencies, bugs, etc (like in case of Xamarin/React Native)
Cons
• Setting it up and using it needs a lot of extra work: you need to setup additional compile steps and write wrappers for both platforms.
• Some other challenges you're surely going to meet when trying to compile the same code for two different architectures
Here's a SO post on how to do it in detail...
2. Xamarin
This option seems to extreme to use in this case. You're forced to use C# and introduce another layer of dependencies and bugs. You said you don't want to use another language for UI so I wouldn't recommend it.
3. React Native
Now this is a viable option. You can write scripts in JS and use them in native code in both Android and iOS.
Here's an article on how to share code with code examples...
Unfortunately it uses React Native for UI, but you can easily call React Native functions from native code.
There are a lot of downfalls to using this, including the fact that the calls are asynchronous as they're executed on another thread, so you would have to implement some kind of callback system for functions that return something.
Pros
• Seems to be easy to set up and write
Cons
• You'd have to implement a native callback for every function that returns something
• Using it has a lot of downfalls that the document describes:
• As events can be sent from anywhere, they can introduce
spaghetti-style dependencies into your project.
• Events share namespace, which means that you may encounter some name
collisions. Collisions will not be detected statically, what makes
them hard to debug.
• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you'll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view's reactTag as an
identifier).
Conclusion
I think I'd go with C++, mainly because a big company (Dropbox) tried it and succeeded and actually uses it in production. You could try React Native as an experiment, it would make a great study case!
I'd say that putting the "core" logic into a separate library is a sensible approach.
You are not the first who wants to do this, and I highly recommend looking at Djinni. It's a tool to accomplish just that. You can define common interfaces and datatypes and fill in the native parts. Communication is possible in both ways.
It's not as easy as writing the whole thing natively at once, but it supports clean design which you might benefit from anyway.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am having experience in iOS application development in native platform and tools. I have a requirement to port an existing native application to Xamarin platform so that it is only a matter to maintain single code base for multiple platforms. My existing application has following features.
Api calls using AFNetworking Library.
Local caching of data using
Core Data, NSIncremental Store. Core Data migrations are implemented
to support versioning. Also complex mappings are done using many-many
relationship, one-many relationship etc.
Asynchronous and
synchronous network calls.
Listing items using table view controller
with Search Controller. Pagination is implemented in these view
controllers.
One of the views in the application is rendered using
Open GL.
Can all these features be perfectly ported to Xamarin. Does Xamarin provide apis for these features? Any help will be appreciated.
First of all, let me tell you that Xamarin is not about a single code base for all the three platforms, but you could share a good amount of code between the three platforms. But that will depend on each app.
To the best of my Knowledge AFNetworking has a partial support. This is repo for it: https://github.com/paulcbetts/AFNetworking-Xamarin . But if you plan to port your app to xamarin/ cross platform. I would recommnend using a C# variant, check if Modernhttpclient will help you?
Local data caches are very well supported
https://www.nuget.org/packages/SimpleStorage/
https://github.com/akavache/Akavache
Async progrmamming is one of the strengths of C#/xamarin.
https://developer.xamarin.com/guides/cross-platform/advanced/async_support_overview/
TableViewController and Pagination is supported
Hope it helps you to get started with porting your app.
If you aren't using any third party libraries you shouldn't have any problems porting this application to Xamarin.
Before you begin I would advise that you think about any functionality that you can wrap up in a core project and inherit in your iOS and Android projects so that you have the maximum amount of code re-use. Thinking ahead will save you a lot of time.
Also be cautious when using table and collection views. I've previously encountered a solution which was holding on to a lot of memory because the table view cells weren't being deallocated correctly.
Considering you are having experience in iOS application development in native platform and tools. there is going to be a huge learning curve.
Shifting from Android studio to Xamarin(VS2015) was a hectic job for me.
But maintaining the less code for multiple devices is really fun using Xamarin.
your first requirement is answered by this github link here
Asynchronous and synchronous network calls are easy to handle as I am using it in my project so that is not going to be the problem.
Happy Coding
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have an app that has about 10 different components (chat, feed, profile, settings, etc').
I need the ability to create multiple apps that each one of them will have a number of the components.
example:
app1 - will have chat settings and profile.
app2 - will have feed and settings.
How should i approach this?
I was thinking of building each component as a library and then for each app that i need to build a just connect the pieces like a puzzle.
Would this be the correct way? Or does anyone have any better suggestions?
Thanks
You can develop an "SDK" project (like the Facebook SDK) which includes all the components (chat, feeds, profiles, users etc.) and you can use that "SDK" as a library in other projects. Use whichever components you want for that particular app.
This approach will make the "SDK" project maintainable and easily upgradable. When you are adding a new feature (say, albums) you can integrate it into the "SDK" project and use with the existing applications.
An extensible, modular design of this sort is often quite useful for building larger scale software or software designed to handle a wide range of unanticipated future needs, especially if you're mixing in bottom-up approaches.
However, effective ways to approach this vary somewhat depending on the language and tools you are using.
An awkward part is how to make modules able to talk to each other when needed so that you can effectively piece them together like lego blocks. This will often become a practical need as the complexity of your software grows to a point where it will often cease to suffice to simply have modules completely decoupled from each other as stranded islands and only one "master" module to communicate with all of them. Often your needs will grow to require them to start talking to each other.
For example, if you are using a dynamic scripting language like Python, then it's easy for each module to publish its own public interface and you can start making modules talk to each other that way almost effortlessly.
If you are using a compiler and statically-typed language like C or C++, then this becomes a lot more awkward to make each module publish its own unique interface which is being directly imported and used by others. There you face the need to make headers accessible to all modules, worry about preserving ABI as you make changes, etc. A larger number of changes will break ABI and break other modules depending on a particular one's interface, so there we tend to design a bit differently.
In such cases, you almost always want a central software development kit containing all the abstract interfaces. Then your modules implement those interfaces and still communicate with each other, albeit indirectly (plugin A talks to SDK interface which is indirectly communicating with another plugin, B). The SDK establishes that central headquarters of communication, relaying messages from one module to another.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been looking around, in vain, for some information on using a dependency injection container in Android development. Specifically, how to override the creation of an Activity in a way that will also work when coming back from being killed (for whatever reason).
Has anyone got any experience in this area?
It appears you can use Google Guice 2.0 with Android. You might also look into roboguice.
Edit:
Spring is also now available for Android
Edit:
Roboguice is now deprecated. You might try Toothpick as mentioned in the comments by the developer behind Toothpick.
You might also want to consider Spring ME. Although originally intended for Java ME, I have seen reports from people using it for Android as well. The benefit would be that you have a familiar programming model (Spring) without the penalty: Spring ME has a 0k footprint.
If you are used to use Spring in other projects, you won't be very happy with Spring for Android (it's only a REST library with Auth support), Spring ME (completely different workflow and reduced featureset) or Tiny Spring (e.g. only Spring-like configuration).
You could however give my project RoboSpring a try. From the description:
RoboSpring is a (real) port of the Spring Framework to the Android platform. Additionally it offers preliminary support for functionality introduced by RoboGuice like injecting View references into Activities and more. RoboSpring is based on version 3.1.0 RELEASE of Spring's core, beans, context and aop components. It offers the following functionality:
Configure application components with a Spring configuration file
(XML)
Autowire your Android components with beans from the Spring application context.
Inject the Android application context into your Spring Beans.
Inject views into Activities.
… and more
https://github.com/dthommes/RoboSpring
There is also a new Spring project for Android: Tiny Spring. It solves the very basics of XML configuration but doesn't do everything that Spring does.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Coming from J2ME programming are there any similarities that would make it easy to adapt to Android API. Or is Android API completely different from the J2ME way of programming mobile apps.
Actually the Android API is much more powerful than the J2ME.
It is much easier to create an application for the Android.
Using the J2ME you are limited to simple forms due to the absent of swing-like libraries (though now there exists a library called LWUIT, avoiding the need to recreate from scratch a swing-like library).
In Android you will be able to create complex form very quickly, and software package for the android SDK is easy to install (while in J2ME you have to install the wireless development toolkit from sun, or install one of Nokia's, Samsung's or SonyEricsson's... it gets a bit confusing sometimes).
The things I had to change when switching from j2me to android were:
1/ The font and graphics class is easier to use on j2me. The API is more thorough on Android, but also more complicated.
2/ If you are used to the database storage of j2me (RecordStore), well you can forget it in Android. You will have to use a SQL-like databased, so be prepared to rethink your data model.
I've also found the path from Java ME to Android to be pretty simple. Here are a few things I've noticed:
There is ONE ui draw thread in Android. You have to be aware of the difference between calling postInvalidate and invalidate on Views to force them to update.
The actual bit-wise graphic manipulation is very similar. I was able to port large amounts of custom J2ME draw code by writing a few shims for drawRect and drawImage.
Android's UI library is much more extensive, much less useless, and much more complicated than Java ME's
Threadwise, you have to be much more careful about thread saftey with Android. In Java ME you can get away with not making methods synchronous or variables volatile most of the time. Not so in Android.
I will say, on the whole, that Android's UI library fails a critical test. I call this the "roll my own" test.
Your UI library fails this test if it takes me longer to complete a detailed task task (say, changing the background on one individual menu item) than it would take me two write my own Menu from scratch. Android fails the "roll your own" test by a factor of 3 or 4. In fact, if you look, the majority of the questions on this website are "How do I make the Android UI toolkit do my bidding?" questions.
Android is an amazing platform and it has been worth every frustrating moment I've sunk into it. It is, however, a young platform, and needs some serious work in times to come.
A good start would be to watch the Android architecture videos and look at some of the documentation.
http://www.youtube.com/view_play_list?p=586D322B5E2764CF
http://code.google.com/android/what-is-android.html
Google is very good about documenting. From what I've heard Android very very similar to J2ME in its goals. It may be slightly different in programming style and structure but if you have J2ME experience you should be more then ready to move on to Android.
Good Luck!!!
Well, you may not actually need to adapt.
There is a good chance that a J2ME stack will become available for Android before long since Android is not supposed to become as restrictive of third-party runtimes as the iPhone.
I know one guy who has been working on just that:
http://justanapplication.wordpress.com/
Now, of course, that doesn't mean you shouldn't have a look at the Android APIs and application lifecycle.