[aerogear-dev] News from iOS Modules front

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] News from iOS Modules front

Corinne Krych
Hello Guys,

Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.

For iOS we have several actions:

1. rename existing repos (too bad we don’t follow well Android convention)
        • aerogear-ios-crypto
        • aerogear-ios-push (thanks passos for the suggestion)
        • aerogear-ios-otp
        • aerogear-ios-xcode-template
        • aerogear-ios-cookbook

Since we’re talking about renaming, what about dropping “arerogear” for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?

2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
But …. don’t be scared new modules will replace them:

• aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
• aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
• aerogear-ios-storage usage of incrementalStorage to plug into Core Data

Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.

3. Cookbook recipes rpo
• tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
* Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.

4. Differentiate Swift vs Objective-C libs
How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
master -> objc-c
until iOS8 is released and stable.
I’m +1 with that idea.

Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.

++
Corinne

[1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
[3] https://github.com/corinnekrych/aerogear-ios-http
[4] https://github.com/corinnekrych/Weather
[5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Corinne Krych
I forgot a last topic (but not least) to end our iOS modules discussion

5. dynamic framework iOS8
Swift app using speudo objective-c fwk (static lib packaged in fwk shell) works ok
Swift app using dynamic fwk packagec lib still lots of issues in xcode6beta3. We're working on it.

++
Corinne

On Friday, July 11, 2014, Corinne Krych <[hidden email]> wrote:
Hello Guys,

Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.

For iOS we have several actions:

1. rename existing repos (too bad we don’t follow well Android convention)
        • aerogear-ios-crypto
        • aerogear-ios-push (thanks passos for the suggestion)
        • aerogear-ios-otp
        • aerogear-ios-xcode-template
        • aerogear-ios-cookbook

Since we’re talking about renaming, what about dropping “arerogear” for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?

2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
But …. don’t be scared new modules will replace them:

• aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
• aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
• aerogear-ios-storage usage of incrementalStorage to plug into Core Data

Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.

3. Cookbook recipes rpo
• tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
* Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.

4. Differentiate Swift vs Objective-C libs
How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
master -> objc-c
until iOS8 is released and stable.
I’m +1 with that idea.

Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.

++
Corinne

[1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
[3] https://github.com/corinnekrych/aerogear-ios-http
[4] https://github.com/corinnekrych/Weather
[5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Summers Pittman
In reply to this post by Corinne Krych
On 07/11/2014 05:20 PM, Corinne Krych wrote:

> Hello Guys,
>
> Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
>
> For iOS we have several actions:
>
> 1. rename existing repos (too bad we don’t follow well Android convention)
> • aerogear-ios-crypto
> • aerogear-ios-push (thanks passos for the suggestion)
> • aerogear-ios-otp
> • aerogear-ios-xcode-template
> • aerogear-ios-cookbook
>
> Since we’re talking about renaming, what about dropping “arerogear” for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
Less typing, looks better in my bom/gradle/whatever, +1
>
> 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> But …. don’t be scared new modules will replace them:
>
> • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
Yeah I'm not sure if Android will drop Pipe and Store, I personally use
them a lot. But I understand that on other platforms they are much simpler.

>
> Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
>
> 3. Cookbook recipes rpo
> • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
>
> 4. Differentiate Swift vs Objective-C libs
> How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> master -> objc-c
> until iOS8 is released and stable.
> I’m +1 with that idea.
Sounds like a good plan. I don't know if naming '-swift' or '-objc' is
necessary if they are cross compatible, but I'm not that passionate
either way.

--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Daniel Passos-2
In reply to this post by Corinne Krych
On Fri, Jul 11, 2014 at 6:20 PM, Corinne Krych <[hidden email]> wrote:
Hello Guys,

Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.

For iOS we have several actions:

1. rename existing repos (too bad we don’t follow well Android convention)
        • aerogear-ios-crypto
        • aerogear-ios-push (thanks passos for the suggestion)
        • aerogear-ios-otp
        • aerogear-ios-xcode-template
        • aerogear-ios-cookbook

Since we’re talking about renaming, what about dropping “arerogear” for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?

-9001 for dropping “arerogear” for the repo name
 
2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
But …. don’t be scared new modules will replace them:

• aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
• aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
• aerogear-ios-storage usage of incrementalStorage to plug into Core Data

Very nice! 
 
Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.

Sorry but It's not clear for me. We'll not support Objective-C for that? Or will support both?
 
3. Cookbook recipes rpo
• tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
* Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.

4. Differentiate Swift vs Objective-C libs
How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
master -> objc-c
until iOS8 is released and stable.
I’m +1 with that idea.

Agreed with that for now

Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.

++
Corinne

[1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
[3] https://github.com/corinnekrych/aerogear-ios-http
[4] https://github.com/corinnekrych/Weather
[5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

cvasilak
Thanks for your feedback Passos,

On Jul 25, 2014, at 1:27 AM, Daniel Passos <[hidden email]> wrote:

On Fri, Jul 11, 2014 at 6:20 PM, Corinne Krych <[hidden email]> wrote:
Hello Guys,

Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.

For iOS we have several actions:

1. rename existing repos (too bad we don’t follow well Android convention)
        • aerogear-ios-crypto
        • aerogear-ios-push (thanks passos for the suggestion)
        • aerogear-ios-otp
        • aerogear-ios-xcode-template
        • aerogear-ios-cookbook

Since we’re talking about renaming, what about dropping “arerogear” for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?

-9001 for dropping “arerogear” for the repo name
 
2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
But …. don’t be scared new modules will replace them:

• aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
• aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
• aerogear-ios-storage usage of incrementalStorage to plug into Core Data

Very nice! 
 
Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.

Sorry but It's not clear for me. We'll not support Objective-C for that? Or will support both?

we will _aim_ to support objc-c apps that will try to use our fwks written in Swift.  Although there is some great interoperability between the two languages, there are things that need be taken into account when obj-c code accesses swift code (and vice versa) (more information can be found here [1])

Our belief, is that any _new_ fwk is about to head start today, its can be based on Swift. At the end as Apple has stated:

{quote}
Swift is ready to use today, in brand new apps or alongside your proven Objective-C code. We have big plans for the Swift language, including improvements to syntax, and powerful new features.”
{quote}


Thanks,
Christos



 
3. Cookbook recipes rpo
• tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
* Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.

4. Differentiate Swift vs Objective-C libs
How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
master -> objc-c
until iOS8 is released and stable.
I’m +1 with that idea.

Agreed with that for now

Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.

++
Corinne

[1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
[3] https://github.com/corinnekrych/aerogear-ios-http
[4] https://github.com/corinnekrych/Weather
[5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Matthias Wessendorf
In reply to this post by Corinne Krych



On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
Hello Guys,

Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.

For iOS we have several actions:

1. rename existing repos (too bad we don’t follow well Android convention)
        • aerogear-ios-crypto
        • aerogear-ios-push (thanks passos for the suggestion)
        • aerogear-ios-otp
        • aerogear-ios-xcode-template
        • aerogear-ios-cookbook

Since we’re talking about renaming, what about dropping “arerogear” for the repo name?

+1 makes sense
 
all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?

2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
But …. don’t be scared new modules will replace them:

• aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
• aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
• aerogear-ios-storage usage of incrementalStorage to plug into Core Data


+1 all of that sounds awesome!
 

Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.

+1 on Swift!
 

3. Cookbook recipes rpo
• tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
* Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.

yeah
 

4. Differentiate Swift vs Objective-C libs
How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
master -> objc-c
until iOS8 is released and stable.
I’m +1 with that idea.

yeah, let's have ObjC on master now;
The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
 

Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.

++
Corinne

[1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
[3] https://github.com/corinnekrych/aerogear-ios-http
[4] https://github.com/corinnekrych/Weather
[5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Corinne Krych

On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:

>
>
>
> On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> Hello Guys,
>
> Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
>
> For iOS we have several actions:
>
> 1. rename existing repos (too bad we don’t follow well Android convention)
>         • aerogear-ios-crypto
>         • aerogear-ios-push (thanks passos for the suggestion)
>         • aerogear-ios-otp
>         • aerogear-ios-xcode-template
>         • aerogear-ios-cookbook
>
> Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
>
> +1 makes sense


It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.

My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.

@passos and all others guys not in favor for dropping prefix, may I ask why?


>  
> all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
>
> 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> But …. don’t be scared new modules will replace them:
>
> • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
>
>
> +1 all of that sounds awesome!
>  
>
> Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
>
> +1 on Swift!
>  
>
> 3. Cookbook recipes rpo
> • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
>
> yeah
>  
>
> 4. Differentiate Swift vs Objective-C libs
> How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> master -> objc-c
> until iOS8 is released and stable.
> I’m +1 with that idea.
>
> yeah, let's have ObjC on master now;
> The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
>  
>
> Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
>
> ++
> Corinne
>
> [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> [3] https://github.com/corinnekrych/aerogear-ios-http
> [4] https://github.com/corinnekrych/Weather
> [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

danielbevenius
>Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
+1 on dropping the aerogear prefix on the repos.


On 25 July 2014 09:37, Corinne Krych <[hidden email]> wrote:

On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:

>
>
>
> On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> Hello Guys,
>
> Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
>
> For iOS we have several actions:
>
> 1. rename existing repos (too bad we don’t follow well Android convention)
>         • aerogear-ios-crypto
>         • aerogear-ios-push (thanks passos for the suggestion)
>         • aerogear-ios-otp
>         • aerogear-ios-xcode-template
>         • aerogear-ios-cookbook
>
> Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
>
> +1 makes sense


It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.

My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.

@passos and all others guys not in favor for dropping prefix, may I ask why?


>
> all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
>
> 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> But …. don’t be scared new modules will replace them:
>
> • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
>
>
> +1 all of that sounds awesome!
>
>
> Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
>
> +1 on Swift!
>
>
> 3. Cookbook recipes rpo
> • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
>
> yeah
>
>
> 4. Differentiate Swift vs Objective-C libs
> How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> master -> objc-c
> until iOS8 is released and stable.
> I’m +1 with that idea.
>
> yeah, let's have ObjC on master now;
> The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
>
>
> Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
>
> ++
> Corinne
>
> [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> [3] https://github.com/corinnekrych/aerogear-ios-http
> [4] https://github.com/corinnekrych/Weather
> [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Sebastien Blanc
In reply to this post by Corinne Krych



On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:

On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:

>
>
>
> On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> Hello Guys,
>
> Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
>
> For iOS we have several actions:
>
> 1. rename existing repos (too bad we don’t follow well Android convention)
>         • aerogear-ios-crypto
>         • aerogear-ios-push (thanks passos for the suggestion)
>         • aerogear-ios-otp
>         • aerogear-ios-xcode-template
>         • aerogear-ios-cookbook
>
> Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
>
> +1 makes sense


It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.

My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.

@passos and all others guys not in favor for dropping prefix, may I ask why?

If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
 


>
> all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
>
> 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> But …. don’t be scared new modules will replace them:
>
> • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
>
>
> +1 all of that sounds awesome!
>
>
> Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
>
> +1 on Swift!
>
>
> 3. Cookbook recipes rpo
> • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
>
> yeah
>
>
> 4. Differentiate Swift vs Objective-C libs
> How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> master -> objc-c
> until iOS8 is released and stable.
> I’m +1 with that idea.
>
> yeah, let's have ObjC on master now;
> The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
>
>
> Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
>
> ++
> Corinne
>
> [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> [3] https://github.com/corinnekrych/aerogear-ios-http
> [4] https://github.com/corinnekrych/Weather
> [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Corinne Krych

On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:

>
>
>
> On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
>
> On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
>
> >
> >
> >
> > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > Hello Guys,
> >
> > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> >
> > For iOS we have several actions:
> >
> > 1. rename existing repos (too bad we don’t follow well Android convention)
> >         • aerogear-ios-crypto
> >         • aerogear-ios-push (thanks passos for the suggestion)
> >         • aerogear-ios-otp
> >         • aerogear-ios-xcode-template
> >         • aerogear-ios-cookbook
> >
> > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> >
> > +1 makes sense
>
>
> It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
>
> My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
>
> @passos and all others guys not in favor for dropping prefix, may I ask why?
>
> If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
>  

Yeap we’ll keep aerogear as a prefix for cocoapods
https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18

Good question: What about the other modules?

>
>
> >
> > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> >
> > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > But …. don’t be scared new modules will replace them:
> >
> > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> >
> >
> > +1 all of that sounds awesome!
> >
> >
> > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> >
> > +1 on Swift!
> >
> >
> > 3. Cookbook recipes rpo
> > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> >
> > yeah
> >
> >
> > 4. Differentiate Swift vs Objective-C libs
> > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > master -> objc-c
> > until iOS8 is released and stable.
> > I’m +1 with that idea.
> >
> > yeah, let's have ObjC on master now;
> > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> >
> >
> > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> >
> > ++
> > Corinne
> >
> > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > [3] https://github.com/corinnekrych/aerogear-ios-http
> > [4] https://github.com/corinnekrych/Weather
> > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Matthias Wessendorf



On Fri, Jul 25, 2014 at 9:50 AM, Corinne Krych <[hidden email]> wrote:

On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:

>
>
>
> On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
>
> On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
>
> >
> >
> >
> > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > Hello Guys,
> >
> > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> >
> > For iOS we have several actions:
> >
> > 1. rename existing repos (too bad we don’t follow well Android convention)
> >         • aerogear-ios-crypto
> >         • aerogear-ios-push (thanks passos for the suggestion)
> >         • aerogear-ios-otp
> >         • aerogear-ios-xcode-template
> >         • aerogear-ios-cookbook
> >
> > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> >
> > +1 makes sense
>
>
> It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
>
> My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
>
> @passos and all others guys not in favor for dropping prefix, may I ask why?
>
> If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
>

Yeap we’ll keep aerogear as a prefix for cocoapods
https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18

Good question: What about the other modules?

hrm, yeah .... I am bit concerned there.... 

perhaps.... not sure, keep the aerogear ? but yeah it feels duplicated ...

 

>
>
> >
> > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> >
> > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > But …. don’t be scared new modules will replace them:
> >
> > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> >
> >
> > +1 all of that sounds awesome!
> >
> >
> > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> >
> > +1 on Swift!
> >
> >
> > 3. Cookbook recipes rpo
> > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> >
> > yeah
> >
> >
> > 4. Differentiate Swift vs Objective-C libs
> > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > master -> objc-c
> > until iOS8 is released and stable.
> > I’m +1 with that idea.
> >
> > yeah, let's have ObjC on master now;
> > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> >
> >
> > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> >
> > ++
> > Corinne
> >
> > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > [3] https://github.com/corinnekrych/aerogear-ios-http
> > [4] https://github.com/corinnekrych/Weather
> > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

qmx
Administrator
In reply to this post by Corinne Krych
On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote:
> Since we’re talking about renaming, what about dropping “arerogear”
> for the repo name? all those repos belong to aerogear organization
> anyway. Maybe removing the aerogear part will stress more the small
> libraries aspect. Maybe sth we already discussed but can’t
> remember/find it. wdyt?
-1

Rationale: the organization namespace only exists on github - when you
clone the projects you'll end up with a ton of folders with loose
naming - so having the prefix keeps it organized on disk + gives us a
nice boost for the 'aerogear' brand.

I can say that here where I have a bazillion of opensource projects,
it's nice to have all aerogear stuff properly sorted - less cognitive
load for contributors.

--
qmx
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Matthias Wessendorf



On Fri, Jul 25, 2014 at 2:04 PM, Douglas Campos <[hidden email]> wrote:
On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote:
> Since we’re talking about renaming, what about dropping “arerogear”
> for the repo name? all those repos belong to aerogear organization
> anyway. Maybe removing the aerogear part will stress more the small
> libraries aspect. Maybe sth we already discussed but can’t
> remember/find it. wdyt?
-1

Rationale: the organization namespace only exists on github - when you
clone the projects you'll end up with a ton of folders with loose
naming - so having the prefix keeps it organized on disk + gives us a
nice boost for the 'aerogear' brand.

yeah :-) 

ok, let's keep the 'aerogear' :-) 
 

I can say that here where I have a bazillion of opensource projects,
it's nice to have all aerogear stuff properly sorted - less cognitive
load for contributors.

--
qmx
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Corinne Krych
In reply to this post by qmx

On 25 Jul 2014, at 14:04, Douglas Campos <[hidden email]> wrote:

> On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote:
>> Since we’re talking about renaming, what about dropping “arerogear”
>> for the repo name? all those repos belong to aerogear organization
>> anyway. Maybe removing the aerogear part will stress more the small
>> libraries aspect. Maybe sth we already discussed but can’t
>> remember/find it. wdyt?
> -1
>
> Rationale: the organization namespace only exists on github - when you
> clone the projects you'll end up with a ton of folders with loose
> naming - so having the prefix keeps it organized on disk + gives us a
> nice boost for the 'aerogear' brand.
>
> I can say that here where I have a bazillion of opensource projects,
> it's nice to have all aerogear stuff properly sorted - less cognitive
> load for contributors.
>

Oki.
we stick to ag prefix.
no rush on that.
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Bruno Oliveira
In reply to this post by Corinne Krych
Hi Corinne,

I'm not against removing the prefix, but to keep the consistency, if the
remove is called potatos-iOS, it must have the same name on Cocoapods.

We discussed this during the F2F about getting rid of the prefix, but I'm not
sure what has changed now to other team members. Regarding the argument
of keeping it organized, that's not valid to me, is always possible to create a
folder with all the projects inside.

But if most of the team disagree, seems like our suggestion during the
meeting is not valid anymore.


On 2014-07-25, Corinne Krych wrote:

>
> On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:
>
> >
> >
> >
> > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
> >
> > On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > > Hello Guys,
> > >
> > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> > >
> > > For iOS we have several actions:
> > >
> > > 1. rename existing repos (too bad we don’t follow well Android convention)
> > >         • aerogear-ios-crypto
> > >         • aerogear-ios-push (thanks passos for the suggestion)
> > >         • aerogear-ios-otp
> > >         • aerogear-ios-xcode-template
> > >         • aerogear-ios-cookbook
> > >
> > > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> > >
> > > +1 makes sense
> >
> >
> > It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
> >
> > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
> >
> > @passos and all others guys not in favor for dropping prefix, may I ask why?
> >
> > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
> >
>
> Yeap we’ll keep aerogear as a prefix for cocoapods
> https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18
>
> Good question: What about the other modules?
>
> >
> >
> > >
> > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> > >
> > > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > > But …. don’t be scared new modules will replace them:
> > >
> > > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> > >
> > >
> > > +1 all of that sounds awesome!
> > >
> > >
> > > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> > >
> > > +1 on Swift!
> > >
> > >
> > > 3. Cookbook recipes rpo
> > > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> > >
> > > yeah
> > >
> > >
> > > 4. Differentiate Swift vs Objective-C libs
> > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > > master -> objc-c
> > > until iOS8 is released and stable.
> > > I’m +1 with that idea.
> > >
> > > yeah, let's have ObjC on master now;
> > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> > >
> > >
> > > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> > >
> > > ++
> > > Corinne
> > >
> > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > > [3] https://github.com/corinnekrych/aerogear-ios-http
> > > [4] https://github.com/corinnekrych/Weather
> > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Matthias Wessendorf



On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira <[hidden email]> wrote:
Hi Corinne,

I'm not against removing the prefix, but to keep the consistency, if the
remove is called potatos-iOS, it must have the same name on Cocoapods.

We discussed this during the F2F about getting rid of the prefix, but I'm not
sure what has changed now to other team members. Regarding the argument
of keeping it organized, that's not valid to me, is always possible to create a
folder with all the projects inside.

But if most of the team disagree, seems like our suggestion during the
meeting is not valid anymore.

* gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah
** forks... there is still the "forked from gh/ag/foo"

* on java, we have APIs and JAR names, I'd think the aerogear name is still visible there.
the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages)
* On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah)

And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name.
Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand.

-Matthias
 


On 2014-07-25, Corinne Krych wrote:
>
> On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:
>
> >
> >
> >
> > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
> >
> > On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > > Hello Guys,
> > >
> > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> > >
> > > For iOS we have several actions:
> > >
> > > 1. rename existing repos (too bad we don’t follow well Android convention)
> > >         • aerogear-ios-crypto
> > >         • aerogear-ios-push (thanks passos for the suggestion)
> > >         • aerogear-ios-otp
> > >         • aerogear-ios-xcode-template
> > >         • aerogear-ios-cookbook
> > >
> > > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> > >
> > > +1 makes sense
> >
> >
> > It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
> >
> > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
> >
> > @passos and all others guys not in favor for dropping prefix, may I ask why?
> >
> > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
> >
>
> Yeap we’ll keep aerogear as a prefix for cocoapods
> https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18
>
> Good question: What about the other modules?
>
> >
> >
> > >
> > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> > >
> > > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > > But …. don’t be scared new modules will replace them:
> > >
> > > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> > >
> > >
> > > +1 all of that sounds awesome!
> > >
> > >
> > > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> > >
> > > +1 on Swift!
> > >
> > >
> > > 3. Cookbook recipes rpo
> > > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> > >
> > > yeah
> > >
> > >
> > > 4. Differentiate Swift vs Objective-C libs
> > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > > master -> objc-c
> > > until iOS8 is released and stable.
> > > I’m +1 with that idea.
> > >
> > > yeah, let's have ObjC on master now;
> > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> > >
> > >
> > > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> > >
> > > ++
> > > Corinne
> > >
> > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > > [3] https://github.com/corinnekrych/aerogear-ios-http
> > > [4] https://github.com/corinnekrych/Weather
> > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Matthias Wessendorf
Hi,

the "aerogear-push-ios-registration" repo has been renamed to "aerogear-ios-push"



On Fri, Jul 25, 2014 at 4:22 PM, Matthias Wessendorf <[hidden email]> wrote:



On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira <[hidden email]> wrote:
Hi Corinne,

I'm not against removing the prefix, but to keep the consistency, if the
remove is called potatos-iOS, it must have the same name on Cocoapods.

We discussed this during the F2F about getting rid of the prefix, but I'm not
sure what has changed now to other team members. Regarding the argument
of keeping it organized, that's not valid to me, is always possible to create a
folder with all the projects inside.

But if most of the team disagree, seems like our suggestion during the
meeting is not valid anymore.

* gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah
** forks... there is still the "forked from gh/ag/foo"

* on java, we have APIs and JAR names, I'd think the aerogear name is still visible there.
the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages)
* On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah)

And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name.
Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand.

-Matthias
 


On 2014-07-25, Corinne Krych wrote:
>
> On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:
>
> >
> >
> >
> > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
> >
> > On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > > Hello Guys,
> > >
> > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> > >
> > > For iOS we have several actions:
> > >
> > > 1. rename existing repos (too bad we don’t follow well Android convention)
> > >         • aerogear-ios-crypto
> > >         • aerogear-ios-push (thanks passos for the suggestion)
> > >         • aerogear-ios-otp
> > >         • aerogear-ios-xcode-template
> > >         • aerogear-ios-cookbook
> > >
> > > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> > >
> > > +1 makes sense
> >
> >
> > It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
> >
> > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
> >
> > @passos and all others guys not in favor for dropping prefix, may I ask why?
> >
> > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
> >
>
> Yeap we’ll keep aerogear as a prefix for cocoapods
> https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18
>
> Good question: What about the other modules?
>
> >
> >
> > >
> > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> > >
> > > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > > But …. don’t be scared new modules will replace them:
> > >
> > > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> > >
> > >
> > > +1 all of that sounds awesome!
> > >
> > >
> > > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> > >
> > > +1 on Swift!
> > >
> > >
> > > 3. Cookbook recipes rpo
> > > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> > >
> > > yeah
> > >
> > >
> > > 4. Differentiate Swift vs Objective-C libs
> > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > > master -> objc-c
> > > until iOS8 is released and stable.
> > > I’m +1 with that idea.
> > >
> > > yeah, let's have ObjC on master now;
> > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> > >
> > >
> > > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> > >
> > > ++
> > > Corinne
> > >
> > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > > [3] https://github.com/corinnekrych/aerogear-ios-http
> > > [4] https://github.com/corinnekrych/Weather
> > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] News from iOS Modules front

Corinne Krych

On 18 Aug 2014, at 14:01, Matthias Wessendorf <[hidden email]> wrote:

> Hi,
>
> the "aerogear-push-ios-registration" repo has been renamed to "aerogear-ios-push"
>
> https://github.com/aerogear/aerogear-ios-push
> https://issues.jboss.org/browse/AGIOS-241

Thanks!

>
> -Matthias
>
>
>
>
> On Fri, Jul 25, 2014 at 4:22 PM, Matthias Wessendorf <[hidden email]> wrote:
>
>
>
> On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira <[hidden email]> wrote:
> Hi Corinne,
>
> I'm not against removing the prefix, but to keep the consistency, if the
> remove is called potatos-iOS, it must have the same name on Cocoapods.
>
> We discussed this during the F2F about getting rid of the prefix, but I'm not
> sure what has changed now to other team members. Regarding the argument
> of keeping it organized, that's not valid to me, is always possible to create a
> folder with all the projects inside.
>
> But if most of the team disagree, seems like our suggestion during the
> meeting is not valid anymore.
>
> * gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah
> ** forks... there is still the "forked from gh/ag/foo"
>
> * on java, we have APIs and JAR names, I'd think the aerogear name is still visible there.
> the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages)
> * On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah)
>
> And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name.
> Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand.
>
> -Matthias
>  
>
>
> On 2014-07-25, Corinne Krych wrote:
> >
> > On 25 Jul 2014, at 09:46, Sebastien Blanc <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych <[hidden email]> wrote:
> > >
> > > On 25 Jul 2014, at 09:13, Matthias Wessendorf <[hidden email]> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych <[hidden email]> wrote:
> > > > Hello Guys,
> > > >
> > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0.
> > > >
> > > > For iOS we have several actions:
> > > >
> > > > 1. rename existing repos (too bad we don’t follow well Android convention)
> > > >         • aerogear-ios-crypto
> > > >         • aerogear-ios-push (thanks passos for the suggestion)
> > > >         • aerogear-ios-otp
> > > >         • aerogear-ios-xcode-template
> > > >         • aerogear-ios-cookbook
> > > >
> > > > Since we’re talking about renaming, what about dropping “arerogear” for the repo name?
> > > >
> > > > +1 makes sense
> > >
> > >
> > > It looks like we don’t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key.
> > >
> > > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that.
> > >
> > > @passos and all others guys not in favor for dropping prefix, may I ask why?
> > >
> > > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ?
> > >
> >
> > Yeap we’ll keep aerogear as a prefix for cocoapods
> > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18
> >
> > Good question: What about the other modules?
> >
> > >
> > >
> > > >
> > > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can’t remember/find it. wdyt?
> > > >
> > > > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 version and will be marked deprecated.
> > > > But …. don’t be scared new modules will replace them:
> > > >
> > > > • aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :)
> > > > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ...
> > > > • aerogear-ios-storage usage of incrementalStorage to plug into Core Data
> > > >
> > > >
> > > > +1 all of that sounds awesome!
> > > >
> > > >
> > > > Those modules will be written in Swift code. We’ll test them both in iOS7 and iOS8.
> > > >
> > > > +1 on Swift!
> > > >
> > > >
> > > > 3. Cookbook recipes rpo
> > > > • tag our repo 1.7: we didn’t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should
> > > > * Swift demo naming convention add “-swift” for Swift version like we did [5]. We should also append “-objc” to other recipes to be consistent.
> > > >
> > > > yeah
> > > >
> > > >
> > > > 4. Differentiate Swift vs Objective-C libs
> > > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches.
> > > > master -> objc-c
> > > > until iOS8 is released and stable.
> > > > I’m +1 with that idea.
> > > >
> > > > yeah, let's have ObjC on master now;
> > > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September)
> > > >
> > > >
> > > > Let me know if you have suggestions/objections. When we reach an agreement, I’ll create associated JIRA.
> > > >
> > > > ++
> > > > Corinne
> > > >
> > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014
> > > > [2]http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt
> > > > [3] https://github.com/corinnekrych/aerogear-ios-http
> > > > [4] https://github.com/corinnekrych/Weather
> > > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev