[aerogear-dev] Modularizing the Android Library

[Corinne Krych]

Hi Passos,

Actually this library sepration is not just an android concern. We need modularity for iOS too. It something we’ve been talking about too in or last iOS meeting [1]. I have created an epic JIRA [2] to track iOS modularity. Once we agreed on library content, we create more sub-tasks.
Here is what I was thinking (here i leave android but same for iOS):

aerogear-android-pipe
aerogear-android-secure-pipe (auth, autz) dependant on aerogear-android-pipe
aerogear-android-store
aerogear-android-push-registration (one of the repo need renaming, for ios we have registration at the end)
aerogear-android-secure-store (keyservices) dependant on aerogear-android-store
aerogear-android-offline dependant on aerogear-android-store
aerogear-android-sync dependant on aerogear-android-pipe (?) and/or aerogear-android-offline
aerogear-ios-crypto

@abstractj I’d keep auth/authz and encryption separate as it has different dependancy one on pipe and another on store. Having small modules gives the user more choice. An app might want auth without encryption for ex.
@passos what is messaging for?

++
Corinne
[1] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-08-11.46.txt
[2] https://issues.jboss.org/browse/AGIOS-192

On 08 May 2014, at 21:28, Bruno Oliveira <bruno at abstractj.org> wrote:

> Aloha,
> 
> My 2 cents here, IMO aerogear-android-security only. It includes all
> the sec requirements like aerogear-crypto-java or authentication with
> OAuth2.
> 
> aerogear-android-store is kinda of a dependency for Offline. So I'm not
> sure if they must stay separated or be a single module.
> 
> On 2014-05-08, Daniel Passos wrote:
>> Hi Folks,
>> 
>> Just to y'all know, that is what we are planning for android modules
>> 
>> aerogear-android-core (pipe, auth, autz)
>> aerogear-android-store
>> aerogear-android-push
>> aerogear-android-security|encrypt (keyservices)
>> aerogear-android-offline
>> aerogear-android-sync
>> aerogear-android-messaging
>> 
>> wdyt?
>> 
>> -- Passos
>> 
>> 
>> On Thu, Mar 6, 2014 at 10:38 AM, Karel Piwko <kpiwko at redhat.com> wrote:
>> 
>>> I believe there should be a POM depchain for users that are willing just
>>> to use
>>> aerogear-android and modular dependencies are for more experienced users.
>>> 
>>> Similarly to *Adding ShrinkWrap Resolvers to your project* at
>>> https://github.com/shrinkwrap/resolver/blob/master/README.asciidoc
>>> 
>>> I'm not sure how nicely that would play with Gradle though.
>>> 
>>> Karel
>>> 
>>> On Wed, 05 Mar 2014 09:15:27 -0500
>>> Summers Pittman <supittma at redhat.com> wrote:
>>> 
>>>> Earlier in development (pre passos) making the Android SDK into modules
>>>> was not a concern (in fact it was an anti-concern).
>>>> 
>>>> Now, however, we have a much more complete project and it is time to
>>>> have that discussion.
>>>> 
>>>> Right now we have two BIG questions:
>>>> 
>>>> 1) Do we want to break out interfaces and implementation?
>>>> 
>>>> If we do this then we could reuse a lot of code to make a aerogear-java
>>>> as well.
>>>> 
>>>> 2) How granular do we want our modules?
>>>> 
>>>> IE If we break out push into aerogear-android-push would that include
>>>> GCM, SimplePush, MQTT, etc in one package or would it look like
>>>> aerogear-android-push-core, aerogear-android-push-mqtt etc.
>>>> 
>>>> Thoughts?
>>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> --
> 
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev