On Tue, May 13, 2014 at 06:54:09PM +0200, Sascha Lüdecke wrote: > Using something like your DocUtils his is exactly the conclusion I > have come to. I will move away from 'proper' domain / business > objects in terms of 'static typing' and move to a 'dynamically typed' > approach: using Document objects all around and assuming that the > content is what I expect. The DocUtils will help me doing basic type > conversions and the domain specific classes - just like the static > ones in ToDo-lite and your translation objects - will help me keeping > my code readable.
Sorry, I might have been a bit unclear due to the example I chose, but I actually still do use POJOs (domain objects or view models). For the same example, in a screen that has a list of tasks, each with a checkbox to mark them completed, we would have (somewhat simplified): - an AsyncTaskLoader that queries a view and maps Document objects to Task objects - a ListAdapter that displays Task objects in a list - a click handler on the checkbox that calls into TaskDataStore.completeTask (the example method above) So, as far as the activity is concerned, it's only working with Task objects. The translation of Document -> Task and Task -> Document happens at the edges. I try to limit the catch-all DocUtils class to things that are common to all of our documents, like type conversion, date parsing/formatting, provenance tracking conventions, etc. > One last question arises: if I have a couple of fields changed, e.g. > after the user edited bis name and birthday and such on a UI screen - > how do you avoid creating revisions for every minor change? Or to put > it otherwise: to you have a pattern / best practice to collate changes > while using the helper classes? Similar to the above, on a screen where you can edit a task, we would: - get the task document, and map to a Task object - populate the form using the Task's properties - modify the Task's properties as the form's values change - call out to e.g. TaskDataStore.save(mTask) in onPause So a user may make many changes to the task document, but it only gets persisted when they leave the screen (so only one revision gets created). Of course you could trigger the save using an explicit "save" button, or whatever makes sense for your app. ...Having said all that, I make no claims that I'm doing anything the "right" way -- they're just the patterns I've settled into over time as our app has grown. I don't want to discourage you from trying things out however you see fit. (And, for simpler cases, I still skip all the type conversion stuff and just use a plain Document, as you've suggested). There isn't much out there by way of conventions for CBL Android yet, and I'm glad to have discussions about how people are approaching coding with it. So, don't be afraid to keep asking! Hopefully other CBLA users chime in about what they're doing too :) -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/20140513174855.GA2588%40mqmb.local. For more options, visit https://groups.google.com/d/optout.
