Mobile SDK Caching Without Liferay Screens?

[David Welch, geändert vor 8 Jahren.]

I recently attended a a Liferay Mobile Roadshow, where it was presented that the Liferay mobile SDK provides a built-in caching mechanism when using native deployment. I've looked through the docs and don't see anywhere that this is provided in the mobile SDK itself.

I do see where there are some caching options provided you use Liferay Screens approach, but, this would be limited to the Screenlets that have been developed (or new ones that you create yourself), and, in implementing SyncManagerDelegate in concert with these Screenlets.

Is this the only way to use caching with the mobile SDK, where the view implementation layer is tied to caching mechanism? This doesn't seem to follow basic mvc principles to me. I'm sure there's a method to use the caching mechanism without using Liferay Screens, maybe I just don't see how it can be done, can someone shed some light?

Greatly appreciated,
David

[Javier Gamarra, geändert vor 8 Jahren.]

Currently the Mobile SDK doesn't have a cache layer (AFAIK) but it shouldn't be hard to implement, specially with the change to okhttp.

But that layer could only be a cache layer and it would be hard to use it as an offline mode, because it doesn't understand the important parameters (like an id for a record) from the optional ones due to the large number of remote services.

The reason Liferay Screens implement it is to allow the programmer to develop offline applications and it assures a more permanent persistence than a cache layer because it has to take care of storing a small subset of remote calls. The widgets Liferay Screens implement are not a view layer per se, are components that cover all the usual "web layers". For example you could use an interactor (like a business component) without the need of showing anything in the screen and using the offline mode.

Both approaches (cache in the mobile SDK and offline in screenlets) have their merits, one is meant to act as a classical cache (like ehcache) and the other as a database/persistent alternate storage.

I could look how to implement/add cache support in the new release of the mobile SDK, it should just be exposing in some way those internal APIs that okhttp is already implementing, if you need that kind of cache mechanism.

As a side note, the mvc pattern doesn't fit in mobile applications as well as it does in a web/standalone app, mainly because the view layer is too large and a classic controller too thin. Popular alternatives (in Android) are a MVP approach or the focus in MVVM solutions with the new data binding library.

[David Welch, geändert vor 8 Jahren.]

Hi Javier:
Thanks for the response, what I'm looking for is caching built into the SDK, as, I am not implementing Screens, and really avoiding platform specific coding and UI for each platform (i.e. XCode, Android SDK). A lot of us out here are trying to avoid doing pure native development for each platform, and using various types of cross-platform development approach.

When you don't have a room full of mobile developers, which, I'm thinking is a big part of Liferay's mantra, you can still build decent mobile apps with these cross-platform tools. Currently, everyone that uses this approach could certainly use the mobile SDK (I am), which is great, but, the caching mechanism is CRITICALLY important in a lot of mobile apps (especially mine), and, it's a killer for some when they have to build it themselves.

And, I didn't want to dispute what I had heard in the mobile seminar, but, it seems that "the SDK has caching" is not a correct statement.

I appreciate your feedback, but, looks like this is a real hit for my mobile effort, which, hinged upon not building native iOS and Android objects just to support a caching layer. But, maybe what you're saying is simpler than I think, are there any examples of using an "interactor" model?

Btw, my multi-platform tool is Apache Flex mobile, which builds real native apps, not hybrid html/JS. We've used it very successfully to build native apps. I've adapted the SDK to use Flex layer (using the SDK builder). It easily builds LR mobile apps for the 3 major platforms with one codebase. But, as this stands, I'd have to write my own (AS3) caching mechanism, which, I think would be better handled in the SDK. The platform does allows embedding any native code (it provides a way to wrap the calls), but, this mostly must be non-UI based, hence my thinking that Screens won't be help here.

Anyway, maybe "interactor" approach and embedding this native code (through this wrapper) might work.


If

[Bruno Farache, geändert vor 8 Jahren.]

Hi guys,

The portal doesn't use any HTTP caching mechanism for remote API calls (no Cache-Control header, no ETags, no 304 Not Modified status code). It considers all requests as dynamic and doesn't check if response content has changed since last request. This means any HTTP client library won't be able to cache responses properly or invalidate them when needed.

Cache in this case would only be useful for offline data access, not for saving up requests or bandwidth. In our apps that use the Mobile SDK we generally persist data with SQLite, which is very app specific, maybe if we move to schemaless database, we could extract something generic enough to put in the Mobile SDK. The hard part would be to synchronize data between server and app once the apps gets online.

[Javier Gamarra, geändert vor 8 Jahren.]

Thanks Bruno, I didn't take into account the response of the current remote APIs (I was only thinking of the client-side work)... if we want headers or etags the solution it comes to my mind would be wrapping up the requests like we're currently doing in the Screens plugin (and then exposing the cache APIs of the mobile SDK). These headers/tags problems are fixed for 7.0 with the new integration with jaxws/rs.

I agree with Bruno that offline capabilities are usually very app specific and should be done in a per-case scenario.

About the need of a room full of mobile developers I amicably disagree, that's why we are wrapping Screens with React Native and testing ionic-based solutions

An example of an interactor approach would be similar to:

DDLFormLoadInteractor ddlFormLoadInteractor = new DDLFormLoadInteractorImpl(0, OfflinePolicy.CACHE_FIRST);
Record record = new Record(locale);
record.setStructureId(structureId);
record.setRecordSetId(recordSetId);
ddlFormLoadInteractor.onScreenletAttachted(this);
ddlFormLoadInteractor.load(record);

That code will load a DDLRecord (with a structureId, locale and recordSetId) with cache support to and call a listener with the result. But it's true that is only the Android code and the iOS version is similar but different.

[David Welch, geändert vor 8 Jahren.]

Thanks Javier, I think this might be a good approach for us, my platform allows a wrapper for native code (similar to the Cordova, many others) that can be called, given it's primarily services and does not have UI. But, it still seems to be tied to Screens. Will we have to write, for example, a Screenlet for Chat? Is it possible that you can you provide an example of the same approach on iOS?

Can this return portal structure, i.e. site configuration, page and layout info also?

And, I politely disagree that "offline capabilities are very app specific". It seems to me that if an application uses LR (and it's structures) for storing data and for managing how it presents data (i.e. page/site configuration), then the actual implementation of caching shouldn't be concerned with what the applications actual usage of the data is. Should each LR customer write their own local data store for mobile usage?

Thanks,
David

[Jose M. Navarro, geändert vor 8 Jahren.]

Hey David

David Welch:

Thanks Javier, I think this might be a good approach for us. Can you provide an example of the same approach that would be on iOS?

The architecture is quite similar in iOS, so the approach would be the same: just create an interactor from scratch and receive the events in the closures when the interaction is done.

let interactor = DDLFormLoadFormInteractor( ... )

interactor.cacheStrategy = .RemoteFirst

interactor.onSuccess = {
    // interaction succeeded
}

interactor.onFailure = { err in
    // interaction failed
}

interactor.start()

However, keep in mind this isn't our main use case, so you may have to tweak some things. Most interactors have a dependency to the screenlet, so you may need to create the screenlet programatically (without using it in the view, just to satisfy the dependency)

If you follow this approach and need to decouple interactors from screenlets, just let us know. Maybe is a good idea to prioritize this task and make the interactors layer useful without the screenlets

[David Welch, geändert vor 8 Jahren.]

Thanks Jose, I'll give this a try, let you know what I find.

[Denis Signoretto, geändert vor 8 Jahren.]

Hi everybody,

since Mobile SDK is based on JSONWS services, generally speaking do you think is possible
define an interface or an abstraction layer for remote services to allow entities and related
operations managed in online/offline mode ?

Bye,
Denis.