Develop Reference

Which is better to handle SQLite between Exposed and Anko in Kotlin?

I know that both Exposed and Anko can operate SQLite easily, could you tell me which one is more better when I develope an Android App?

Use the framework you are most comfortable with. I tried Exposed once and it was ok for what I've used it. jooq might also be a valid alternative instead.
Reading the documentation of both, Room and Anko, I would stick to either one of those.
Regarding which of those, I just found an issue asking the very same question (even though just as a second or third question):
https://github.com/Kotlin/anko/issues/484
Some other resources I found regarding Room and Anko:
Stress-free SQLite with Anko: the comment regarding Anko vs Room is also insightful:
Anko SQLite provides a nice API to manage your data persistence layer but you still have do the heavy lifting by yourself. While Room is more like a framework. Generates databases from annotated classes for you, provides observable queries and has a really nice testing support. Also works well with Android Architecture Components.
Ah... and don't get me wrong. Exposed is ok too, I am still using it ;-) But if you are familiar with both, you may also have your preferred choice already. If you don't know any, you can try both and choose the one where you grasp the documentation more quickly or you feel more comfortable sooner.

Is Xamarin perfect tool for a Camera Surveillance application? [closed]

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

When to use Dagger in android application? [closed]

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.

Ormlite or sqlite Which one is good for Android perspective? [closed]

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 confused the which one good for android perspective either Ormlite or sqlite.
please can you give me suggestion which one is better for use our android app. And makes easy to use and supported all android devices?
I want to use the ormlite in our project but before i want to sure that it will be helfull for me and my app. So please guide me if any one used earlier this. I much appreciate your thought here.Thnaks

ORMLite is an open source software framework that provides lightweight object relational mapping (ORM) between Java classes and SQL databases.
if you use this framework you are ultimately using sqlite database (ORMLite is no database),it allows you to implemet a good architecture to your application, I always prefer using ORMLite
Here is my blog on ORMLite if you want to get started with it!!

ORMLite has two .jar files : ormlite-core.jar (275KB) and ormlite-android (50KB) libraries
Advantages :-
Use for complicated database operations
No need to remember to SQL queries
Prefer for big size application
Disadvantages :-
Unnecessarily increase size of application
Little bit slow with compare to greenDao(another ORM)

Although other answers are perfect but I want to mention another aspect about using ORMs such as Ormlite vs SQlite.
ORMs (such as Ormlite) are good to use because they reduce amount of work and code but I've read this and I mention the opinion here:
We generally do not recommend using an Object-Relation Mapping library
unless you have unusually complex data and you have a dire need. They
tend to be complex and require time to learn. If you decide to go with
an ORM you should pay attention to whether or not it is process safe
if your application requires it, as many of the existing ORM solutions
surprisingly are not.

You can also choose to look at Storm (https://github.com/supaldubey/storm/)
It provides neat interface and does not asks to override or implement any base classes for the Models.
It also would auto create and auto upgrade your models
You can add to Gradle and start using easily
In parent:
maven { url "http://dl.bintray.com/cubestack/maven" }
In project Gradle:
dependencies {
compile 'in.cubestack.android.lib:storm:1.0g'
}
Step 1: Define tables:
#Table(name = "DEMO_ENTITY")
class Entity {
#PrimaryKey
#Column(name="ID", type = FieldType.INTEGER)
private int id;
}
Step Two (Define the Database)
Database also have their annotation which can be applied, there can be multiple databases defined.
#Database(name="MY_DB", tables = {Entity.class, AnotherEntity.class}, version = 2)
class Database {}
Step Three (Start Using)
With database ready for us, we may start using it as below:
Retrieval
StormService service = new BaseService(getContext(), Database.class);
List<Entity> savedEntities = service.findAll(Entity.class);
Similarly it has methods to save, delete etc.

Moving to Android from J2ME [closed]

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.