Relaxing inheritance constraint about sugar HOT 7 CLOSED

@stephanenicolas thanks for the suggestion. I agree with you on the constraint it places. Below are some of the reasons why we went this way.. Would like to hear your views on it. Will certainly love to remove that constraint, if there's a better way to do it, while retaining the simplicity and readability intact.

To answer your second question, SugarApp is only needed in the AndroidManifest. If you're planning to do some more work in your own Application class, you could either extend SugarApp or duplicate the code from that class to your own Application class.

The inheritance model enables the near-zero configuration. With a DAO approach, it may need more configuration or set of boilerplate by itself.

Continuing on the inheritance discussion:

Using the inheritance, we're able to detect the entities in your app which helps in DB creation. Also, the syntax looks very readable, since the methods are directly on the object itself.
eg:
new Book("title").save();

from sugar.

Hi Satyan,

quite a prompt answer :) thx.

Regarding the application class inheritance, it would be easy to turn that into a composition. A SugarDatabaseManager could open and close the database and could be added to any app, and the SugarApp class could be turned into a DefaultSugarApp for people would don't use an application class.

I don't see how the DAO could lead to more configuration. Yes, you would have to declare thePOJO classes but a SugarDAO would be as easy to use as the current state of Sugar. It would give something like

Book book =  new Book("title");
new SugarDAO<Book>().save(book);

Again, from a design point of view, mandatory inheritance is really too strong. Not every Android projects creates its own POJO classes, some of them "get" them from a server-side project. Moreover you could want to turn them to Serializable stuff or Parcelable to exchange data between Activities or Fragments. The DAO pattern has been invented for this.

from sugar.

@stephanenicolas certainly worth a try.. Let me think over this. The key would be to keep the setup to absolutely minimal.. I see the advantages though.

from sugar.

Hey @satyan,

I've just read through this and I'd have to agree with @stephanenicolas that the inheritance pattern is just a little too strong for my use cases. I'm one of those people who are relying on a dumb serializable POJO to shunt information between activities etc.

While arguably not as clean as the current implementation, what @stephanenicolas is suggesting in terms of API, coupled with the rest of the ideals of Sugar, is far and away cleaner than that of the alternative libraries. In fact, this simplicity is exactly what drew me to Sugar in the first place. By all means if you can munge Java into a more workable ActiveRecord-like API like you want to, that'd be awesome ;)

FWIW, inheriting the project from SugarApp bothers me less, as I don't have any logic in my application, but I do foresee problems if another library wants to do the same also.

Nathan

from sugar.

Hi all,

Found this discussion interesting... but at least one question comes to mind.

I guess Sugar now uses classpath scanning to look for the persistent classes that extend SugarRecord to find all definitions of sugar records, for example, to manage the database schema.

Now i guess if we do not have extension, we need some other explicit way to know which classes are persistent... This could mean annotations (@entity?) and we keep scanning the classpath for "annotated with it" classes, or have another explicit way to manage the db schema (SugarDBSchema.createFor(Entity1.class, Entity2.class)

or am i missing something?

grts,
Pedro

from sugar.

@pguedes yes Pedro.. You're right. We look for all subclasses of SugarRecord hierarchy and create corresponding tables. I'm favouring the annotations approach for better readability.

I did try it out a few days back. @SugarRecord as annotation instead of inheritance. Most of the things worked through well. Haven't tested it thoroughly yet though.

The ActiveRecord style querying takes a hit, but it does remove the constraint of inheritance. I'd probably introduce both syles parallelly.. So for the time being, people could choose which style works for them.

Going forward, we could deprecate the older style in favour of annotations approach, it that's what is favoured.

from sugar.

This has been implemented in 4df07db.

from sugar.