1:55 a.m.
Thanks for your feedback Passos,
On Jul 25, 2014, at 1:27 AM, Daniel Passos <daniel(a)passos.me> wrote:
On Fri, Jul 11, 2014 at 6:20 PM, Corinne Krych
<corinnekrych(a)gmail.com> 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
[1]
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Co...
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/aerog...
[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
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev