You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Jason Kristian <ja...@apps4u.com.au> on 2014/11/12 04:42:09 UTC

new iOS SDK

HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,
 or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start
as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.

1- I think it should be package managed from the start. — CocoaPods
2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .
3- I should be easy to extend easy to add new collection model classes.
4- I use Good objective-c convention to better interoperate with Swift.
5- Be fun to use..


Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .

 


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>




Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
It is awesome to see all this discussion!  When the existing iOS SDK was made (3 yrs ago), we didn’t know exactly what people would want to use it for / how.  Very cool to be getting input on this!


-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 13, 2014 at 11:46:58 AM, J (n75463@gmail.com) wrote:

Hello,  

I like the idea of a new iOS SDK. Actually, I considered starting to work on something similar. Some comments, as reply to different mails and the google doc.  

> AFNetworking or RESTKit  

My intuition would be to use pure AFNetworking - last time I had a look at RESTKit it felt bloated. I'll have a second look at RESTKit, though.  

> 3rd Party Libraries should be license compatible with Apache Usergrid (preference for Apache 2.0).  

AFNetworking is BSD [1]. Can anybody confirm BSD is "compatible" with the Apache license?  
According to http://programmers.stackexchange.com/a/40580, it is. Apache's licensing FAQ are of no help [2], or I missed it.  

> The one question I have is unit / e2e testing.  

XCTest is supported by XCode out of the box. I personally tend to use Specta [3]. I'm fine with both.  

> should have jSON parser  

There's NSJSONSerialization [4], available since iOS 5. Also, AFNetworking can take care of this using AFHTTPSerializer, as described in [5].  

> should have documented code with Doc Blocks etc  

Yes, documentation should meet requirements of and show up at http://cocoadocs.org. Jazzy [6] looks nice, but did not work for me last time I tried. Appledoc [7] is still around, too.  


What is the minimum iOS version supported by the new SDK?  

I think iOS 7 and up is sufficient, but other people might have other requirements. This would be in line with requirements of AFNetworking version 2.0 [8]. AFNetworking or not, my impression is that new code should use NSURLSession from the start instead of the older NSURLConnection. Latest RESTKit (0.23.3) is still using AFNetworking 1.3 [9] and thus NSURLConnection.  


Then, I have a proposal which may need more discussion and explanation. For the project I am currently working on, I have the requirement that the app is supposed to work offline as well. I need to store all data in CoreData and synchronize if a network connection is available. I see that not everybody needs this functionality but maybe an offline mode/CoreData can still be supported, at least optionally.  

I also like the idea behind AFIncrementalStore [10], which is based on NSIncrementalStore [11]. AFIncrementalStore is outdated and possibly incomplete, there are some newer forks [13, 14]. Personally, I would love to see a NSIncrementalStore based solution.  

Greetings,  
Jahn  


[1] https://github.com/AFNetworking/AFNetworking/blob/master/LICENSE  
[2] http://apache.org/foundation/license-faq.html  
[3] https://github.com/specta/specta  
[4] https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSJSONSerialization_Class  
[5] https://github.com/AFNetworking/AFNetworking/wiki/AFNetworking-2.0-Migration-Guide#serialization  
[6] https://github.com/realm/jazzy  
[7] http://gentlebytes.com/appledoc/  
[8] http://nshipster.com/afnetworking-2  
[9] https://github.com/RestKit/RestKit/blob/v0.23.3/RestKit.podspec#L49  
[10] https://github.com/AFNetworking/AFIncrementalStore  
[11] https://developer.apple.com/Library/mac/documentation/CoreData/Reference/NSIncrementalStore_Class/index.html  
[12] https://github.com/AFNetworking/AFIncrementalStore/network  
[13] https://github.com/Spaceman-Labs/AFIncrementalStore/tree/gs_threading_sorted  


Re: new iOS SDK

Posted by J <n7...@gmail.com>.
Hello,

I like the idea of a new iOS SDK. Actually, I considered starting to work on something similar. Some comments, as reply to different mails and the google doc.

> AFNetworking or RESTKit

My intuition would be to use pure AFNetworking - last time I had a look at RESTKit it felt bloated. I'll have a second look at RESTKit, though.

> 3rd Party Libraries should be license compatible with Apache Usergrid (preference for Apache 2.0).

AFNetworking is BSD [1]. Can anybody confirm BSD is "compatible" with the Apache license?
According to http://programmers.stackexchange.com/a/40580, it is. Apache's licensing FAQ are of no help [2], or I missed it.

> The one question I have is unit / e2e testing.

XCTest is supported by XCode out of the box. I personally tend to use Specta [3]. I'm fine with both.

> should have jSON parser

There's NSJSONSerialization [4], available since iOS 5. Also, AFNetworking can take care of this using AFHTTPSerializer, as described in [5].

> should have documented code with Doc Blocks etc

Yes, documentation should meet requirements of and show up at http://cocoadocs.org. Jazzy [6] looks nice, but did not work for me last time I tried. Appledoc [7] is still around, too.


What is the minimum iOS version supported by the new SDK?

I think iOS 7 and up is sufficient, but other people might have other requirements. This would be in line with requirements of AFNetworking version 2.0 [8]. AFNetworking or not, my impression is that new code should use NSURLSession from the start instead of the older NSURLConnection. Latest RESTKit (0.23.3) is still using AFNetworking 1.3 [9] and thus NSURLConnection.


Then, I have a proposal which may need more discussion and explanation. For the project I am currently working on, I have the requirement that the app is supposed to work offline as well. I need to store all data in CoreData and synchronize if a network connection is available. I see that not everybody needs this functionality but maybe an offline mode/CoreData can still be supported, at least optionally.

I also like the idea behind AFIncrementalStore [10], which is based on NSIncrementalStore [11]. AFIncrementalStore is outdated and possibly incomplete, there are some newer forks [13, 14]. Personally, I would love to see a NSIncrementalStore based solution.

Greetings,
Jahn


[1] https://github.com/AFNetworking/AFNetworking/blob/master/LICENSE
[2] http://apache.org/foundation/license-faq.html
[3] https://github.com/specta/specta
[4] https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSJSONSerialization_Class
[5] https://github.com/AFNetworking/AFNetworking/wiki/AFNetworking-2.0-Migration-Guide#serialization
[6] https://github.com/realm/jazzy
[7] http://gentlebytes.com/appledoc/
[8] http://nshipster.com/afnetworking-2
[9] https://github.com/RestKit/RestKit/blob/v0.23.3/RestKit.podspec#L49
[10] https://github.com/AFNetworking/AFIncrementalStore
[11] https://developer.apple.com/Library/mac/documentation/CoreData/Reference/NSIncrementalStore_Class/index.html
[12] https://github.com/AFNetworking/AFIncrementalStore/network
[13] https://github.com/Spaceman-Labs/AFIncrementalStore/tree/gs_threading_sorted


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
Just to let every one know I’m starting the new iOS SDK on Monday the repo is private at the moment once Ive had a day or two to get some code in there I’ll make it public. Also Ive had some reply which I’m grateful for . I’ll might need some directions once I get going , once Ive got the network layer out of the way then I’ll ask for some input in the public interfaces to the SDK just to make sure every one is happy. I know this is going to be a decent job but as I said I can put myself and one staff on this till  the new year which is around 6 weeks so I sure I can get it done with testing and all by then. If there is any thing I need to change or keep in mind for Usergrid Version 2.0 please let me know. 

Also there is one thing I wanted to ask one of the  java developers . I would like to added a basic logging feature to the SDK so instead of using a collection I was thinking a hidden collection now I not talking about full on crash reports but just a remote log for all NSLog calls and event a bit like Test flight just basic events and logs.. So once Im near the end off this.  I would like help on the Java usergrid end to add some endpoints. So if anyone is interested in that feature drop me a line and I can tell you the api endpoints to create or you might have a better idea on how to save the Slog calls.
 

Thanks for every one who’s given me input.


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 21 Nov 2014, at 4:17 pm, jasonk@apps4u.com.au wrote:
> 
> Diagram of network layer its not the class map but just a flow diagram of how I propose the network layer works
> 
> November 19 2014 4:38 PM, "Jason Kristian" <ja...@apps4u.com.au> wrote: 
>> Base Class. eg: Usergrid
>> One main Base Class that will be responsible for
>> Org and App name init.
>> Login
>> Oauth 2 (get token stash it and use in http header).
>> Push Messaging registration
>> One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once .
>> Block based async call backs. The base class will also be able to vend a http client to make http
>> calls. As most applications will be interacting with other online api’s other than Usergrid so
>> instead of making the user use some other network library and to make managing bandwidth better.
>> The SDK will have a Session manager should take care of all request and manage and create
>> NSURLSessions. So the SDK will manage two NSURLSession objects one for interacting with Usergrid
>> and have the correct headers (token) and a 2nd session to work with other api so when I ask for the
>> http client the sdk will configure a default NSURLSession or I can pass in a
>> NSURLSessionConfiguration object which will let the SDK create a session and pass me a http client.
>> Which will let the user set priority levels on requests and have a better user experience for the
>> customer by having a responsive UI.
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <ma...@apps4u.com.au>
>> 
>>> On 19 Nov 2014, at 4:25 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>> 
>>> HI Ive added this to the Google Doc on the iOS SDK proposal . This is just the start so I’ll
>> create
>>> a class diagram using mind maps but I think I’ve covered the most important bits let me know if
>>> I’ve missed anything please. As they say two heads are better then one.
>>> 
>>> Base Class. eg: Usergrid
>>> One main Base Class that will be responsible for
>>> Org and App name init.
>>> Login
>>> Oauth 2 (get token stash it and use in http header).
>>> Push Messaging registration
>>> One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once
>> .
>>> Block based async call backs. The base class will also be able to vend a http client to make http
>>> calls. As most applications will be interacting with other online api’s other than Usergrid so
>>> instead of making the user use some other network library and to make managing bandwidth better.
>>> The one Session manager should take care of all request so I might have two NSURLSession objects
>>> one for interacting with Usergrid and have the correct headers (token) and a 2nd session manager
>> to
>>> work with so other api which will let the user set priority level on requests and have a better
>>> user experience for the customer.
>>> 
>>> Base Model eg: BaseEntity
>>> Base Model object class. Now I like the model to be responsible for CRUD like operations now some
>>> people might balk at this but that because when its not done right it gives you bloated classes
>> and
>>> lots of repeated code but Objective-C has a design pattern to solve this issue. So each Model
>> class
>>> will have a http delegate so when I ask the User model to fetch based on a query it will pass the
>>> query along to it http client delegate to make the http call and give me the response in a block.
>>> So when using this SDK I can create a subclass of the base Entity and the min I would need to do
>> it
>>> set its type property so when asking the custom model to fetch or save data it can pass the type
>>> string to the HTTP delegate to know which uri to access. This also fits in with MVC pattern of
>>> Objective-c iOS applications.
>>> 
>>> Now when a response returns more than one entity it give you a collection object , which will map
>>> well into swift which will have typed collections. which will be a array Controller subclass.
>>> 
>>> So Usergrid Collections will not need a class its all wrapped up in the model object either a
>>> single entity or collection of entities.
>>> 
>>> creating a new Usergrid collection will just require the saving of a entity of a new collection
>>> type.
>>> 
>>> I think it should abstract away the network layer for working with models object that way only
>> the
>>> users that want to interact with the network layer have too eg: [User getByQuery:@”select where
>>> name=’tim’”]; [User save:dictionary]; [User create:dictionary];
>>> 
>>> Cache Object.
>>> There will be a cache that the user can enable and set timeout on. For example each requests
>>> response can be cached at the network layer using a HTTP cache or we can just serialize the json
>>> response to disk as either a json file or plist file using a NSEncoder. This solves the issue of
>>> off line use and is a lot easier to implement than core data and is cheap in resources and easy
>> to
>>> throw away and rebuild and does not require the User to be an expert in objective-c as Core data
>>> take time to master and lots of iOS developers don't know how to use it well , I’ve been
>>> programming on Mac OS X since before the iPhone came out and I still learn new things about Core
>>> Data.
>>> 
>>> Events and Counters. (logging??)
>>> The counter api should be easy to use so UI controls should have categories that log their use
>> and
>>> the counter api should do most of UI event tracking without users of the sdk having to do
>> anything
>>> now if they want custom counter then they can create one but it should tack ui event for you .
>> This
>>> will require the sdk to setup some custom counters. It can get the tag of a UI control so if you
>>> have a special button that you want to track and set the tag on it so it can be queried latter. I
>>> think that there should be some remote logging that can be turn on that either send to a
>> collection
>>> or add a url endpoint to Usergrid. just basic logs (like Testflight remote log’s).
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>> ph: +61 075699 8109
>>> mob: +61 0411 389 392
>>> e: Jason Kristian <ma...@apps4u.com.au>
>>> 
>>>> On 19 Nov 2014, at 5:34 am, Rod Simpson <ro...@rodsimpson.com> wrote:
>>>> 
>>>> Good stuff! Sounds like you have a good handle on the use-cases that are specific to iOS. I have
>>>> only built one app with iOS so can’t give as much input on that platform specifically. I am
>>> really
>>>> looking forward to what you come up with!
>>>> 
>>>> Rod
>>>> 
>>>> --
>>>> Rod Simpson
>>>> @rockerston
>>>> rodsimpson.com
>>>> 
>>>> On November 17, 2014 at 9:47:58 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>>> 
>>>> Thanks for feed back
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>> ph: +61 075699 8109
>>>> mob: +61 0411 389 392
>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>> 
>>>>> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>> 
>>>>> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I
>>>> wanted
>>>>> to tackle this SDK after I’d did the PHP version , To take paging as one example I would give
>>>> users
>>>>> both options where there is a easy Iterator type method that can say page in lots of 20 for a
>>>>> UITable view but if you have some custom UICollectionView and you want to handle paging your
>>> self
>>>>> then you can just pass the cursor along for you next call(page)
>>>>> As with Models Object . I have two ways or more to deal with them for example some people like
>>> be
>>>>> able to ask the model for data and let it do the REST call behind the scenes for them other
>>>> people
>>>>> like making the API call and just getting back model objects so this is one of the reason I
>>>> wanted
>>>>> to start this to get every ones input as there is a log of decisions to be made and I did't
>> want
>>>> to
>>>>> make them all my self as per my preferences.
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>> ph: +61 075699 8109
>>>>> mob: +61 0411 389 392
>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>> 
>>>>>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
>> wrote:
>>>>>> 
>>>>>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl). Jason, I know
>>>> you
>>>>>> have already been through this with PHP, but since you are spurring this really awesome
>>>>> discussion,
>>>>>> I thought I would throw in some thoughts. I added this copy to the doc, but pasting it here
>> for
>>>>>> general review.
>>>>>> 
>>>>>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API
>>>> is
>>>>>> big and full featured and there are a few inconsistencies which can create landmines.
>>>>>> 
>>>>>> I think the first thing is to decide how you will keep track of “management” type features
>> such
>>>>> as
>>>>>> logins. Do these go in a user entity object? Do they go in a client object? Where do you keep
>>>>> track
>>>>>> of the current token or client secret/id that will need to be sent along with every call? They
>>>>>> “belong” to the user, but they are used for every API call.
>>>>>> 
>>>>>> Also, should the SDK have higher level constructs (objects) that model the way the data is
>>>> stored
>>>>>> on the server (e.g. collection, entity)? We did this in the Javascript and Node.js SDKs. These
>>>>>> enable a bit more abstraction and may make it easier to use.
>>>>>> 
>>>>>> The problem is that not all the collections behave the same way. For example, the Users
>>>>> collection
>>>>>> uses “username” has a primary key, whereas groups use “path”, and custom collections use
>>> “name”.
>>>>> So
>>>>>> one could create a base entity / collection class, then extending it to map to the different
>>>>> types
>>>>>> of entities / collections - built in, and custom. In the JS SDK, the collection objects hold a
>>>>> set
>>>>>> of entity objects that correspond to the current result set.
>>>>>> 
>>>>>> Another problem we ran into on the JS SDK is paging. Usergrid uses the concept of a cursor for
>>>>>> result sets that have more than one “page” of data. By default, a page is 10 entities, but it
>>>> can
>>>>>> easily be extended to any number up to 1000. So what you do is make a call with your query,
>>>> which
>>>>>> then gives you back 10 entities and a cursor to get the next 10. You pass that cursor along
>>> with
>>>>>> the next call, which will give you back the next 10 and a cursor. Repeat until you get to the
>>>> end
>>>>>> of the result set. Most apps need to use paging to show results since you generally don’t want
>>>> to
>>>>>> pull down 1000 entities every time. In the JS SDK, we did something like this:
>>>>>> 
>>>>>> var books;
>>>>>> 
>>>>>> client.createCollection(options, function (err, collection) {
>>>>>> books = collection;
>>>>>> if (err) {
>>>>>> alert("Couldn't get the list of books.");
>>>>>> } else {
>>>>>> while(books.hasNextEntity()) {
>>>>>> var book = books.getNextEntity();
>>>>>> alert(book.get("title")); // Output the title of the book
>>>>>> }
>>>>>> }
>>>>>> });
>>>>>> 
>>>>>> So the client has a factory method that hands back a collection. Then, you can simply call
>>>>>> getNextEntity on the object to loop through the current page of data. If you want to iterate
>>>>>> through pages, you can use the getNextPage method:
>>>>>> 
>>>>>> if (dogs.hasNextPage()) {
>>>>>> // There is a next page, so get it from the server
>>>>>> dogs.getNextPage(function(err){
>>>>>> if (err) {
>>>>>> // Error - could not get next page of dogs
>>>>>> } else {
>>>>>> // Success - got next page of dogs, so do something with it
>>>>>> while(dogs.hasNextEntity()) {
>>>>>> // Get a reference to the dog
>>>>>> dog = dogs.getNextEntity();
>>>>>> // Do something with the entity
>>>>>> var name = dog.get('name');
>>>>>> }
>>>>>> }
>>>>>> });
>>>>>> }
>>>>>> 
>>>>>> It took some doing to make sure that the logic for paging was sound, because the result sets
>>>>> don’t
>>>>>> give you back a cursor for the previous page - only the next page. So you have to hang onto
>>> them
>>>>>> and build a stack.
>>>>>> 
>>>>>> I’m not saying this needs to be done this way, just something to think about.
>>>>>> 
>>>>>> --
>>>>>> Rod Simpson
>>>>>> @rockerston
>>>>>> rodsimpson.com <http://rodsimpson.com/>
>>>>>> 
>>>>>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>>>>> 
>>>>>> HI to all Ive now made sure that the Google doc has got read / write access when opening with
>>>>> that
>>>>>> link . It would be good if any one had input to speak up now as this will be a better SDK when
>>>>> all
>>>>>> the Usergrid comunity has input so every idea and most users needs can be catered for. I was
>>>>> hoping
>>>>>> to get the design done by the end of this week so I can start on this the last week of
>> November
>>>>>> which should let me get it done hopefully just before Christmas.
>>>>>> 
>>>>>> Thanks add you input the proposal doc.
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>> ph: +61 075699 8109
>>>>>> mob: +61 0411 389 392
>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>> 
>>>>>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>>> 
>>>>>>> this link has edit permission
>>>>>>> 
>>>>>>> 
>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>
>>>>>>> 
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>> ph: +61 075699 8109
>>>>>>> mob: +61 0411 389 392
>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>>> 
>>>>>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>>>> 
>>>>>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will
>>>>>>> contain
>>>>>>>> UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.
>>>>>>>> 
>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>> ph: +61 075699 8109
>>>>>>>> mob: +61 0411 389 392
>>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>>>> 
>>>>>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned
>> is
>>>>>>> Unit
>>>>>>>> /
>>>>>>>>> e2e tests. It would be great if we were designing those from the start. Also, samples. It
>>>>> would
>>>>>>>> be
>>>>>>>>> awesome if we had some samples - especially for the get-up-and-going things.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Rod Simpson
>>>>>>>>> @rockerston
>>>>>>>>> rodsimpson.com <http://rodsimpson.com/>
>>>>>>>>> 
>>>>>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:
>>>>>>>>> 
>>>>>>>>> Jason,
>>>>>>>>> 
>>>>>>>>> Nice way to start this out!
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>>>>> 
>>>>>>>>> I am reviewing now.
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Rod Simpson
>>>>>>>>> @rockerston
>>>>>>>>> rodsimpson.com
>>>>>>>>> 
>>>>>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>>>>>>>> 
>>>>>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or
>>>>>> suggestions
>>>>>>>>> gave the input as the more input we have the better the end result.
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>>>>> 
>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>>> ph: +61 075699 8109
>>>>>>>>> mob: +61 0411 389 392
>>>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>>>>> 
>>>>>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>>>>>> 
>>>>>>>>>> Cool ,
>>>>>>>>>> 
>>>>>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid
>>>>>> community)
>>>>>>>>> can
>>>>>>>>>> se. Like for example license , stable is it going to be around , etc.
>>>>>>>>>> 
>>>>>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that
>>>>> the
>>>>>>>>> SDK
>>>>>>>>>> be open to use other libraries for just that reason JSON, Network, etc.
>>>>>>>>>> 
>>>>>>>>>> What I really would like to do is put together a proposal and then have the community
>>>> comment
>>>>>> ,
>>>>>>>>>> edit , add ideas to its so we can have a plan and set some guideline for example the usage
>>>> of
>>>>>>>> 3rd
>>>>>>>>>> party Libraries.
>>>>>>>>>> 
>>>>>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I
>>>> think
>>>>>>> we
>>>>>>>>>> should take the approach that it be modular and extendable . All of us that Usergrid in
>>>>>>>>> commercial
>>>>>>>>>> way have all added Api to Usergrid itself or through some Node JS reverse proxy and it
>>> would
>>>>>> be
>>>>>>>>>> good if it was easy to make http calls to custom endpoints using that same SDK.
>>>>>>>>>> 
>>>>>>>>>> I was look at where I could create this proposal document . I was thinking I use Google
>>>> doc’s
>>>>>>>> and
>>>>>>>>>> send to mailing list or is there a places where I could create a proposal document.
>>>>>>>>>> 
>>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>>>> ph: +61 075699 8109
>>>>>>>>>> mob: +61 0411 389 392
>>>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>>>>>>>>>> 
>>>>>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Jason,
>>>>>>>>>>> 
>>>>>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work
>>>>> from
>>>>>>>>> the
>>>>>>>>>>> Apigee SDK. That codebase is quite old and is definitely not the way we would architect
>> it
>>>>>>> from
>>>>>>>>>>> scratch today.
>>>>>>>>>>> 
>>>>>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be
>>>>>>> mindful
>>>>>>>>>> of
>>>>>>>>>>> their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is
>>> perfect.
>>>>>>>>>>> 
>>>>>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing
>> in
>>>>>> the
>>>>>>>>>>> current iOS SDK. At one point, there was some work done with Lua to create a little
>>>>> framework
>>>>>>>>> for
>>>>>>>>>>> testing but it never really went anywhere. Having guardrails in place from the start
>> would
>>>>>>> make
>>>>>>>>>> it
>>>>>>>>>>> a lot easier for other developers to get in and help work on the project.
>>>>>>>>>>> 
>>>>>>>>>>> #4, interoperation with Swift would be great.
>>>>>>>>>>> 
>>>>>>>>>>> What are you thinking about for handling JSON?
>>>>>>>>>>> 
>>>>>>>>>>> And of course, #5 would be icing on the cake :)
>>>>>>>>>>> 
>>>>>>>>>>> Rod
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Rod Simpson
>>>>>>>>>>> @rockerston
>>>>>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>>>>>>>>>> 
>>>>>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au
>>>>>>>>>>> <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au
>> <ma...@apps4u.com.au>>)
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now
>>>>> there
>>>>>>>>> are
>>>>>>>>>> a
>>>>>>>>>>> few options on what can be done for example with could build on the current SDK or fork
>>>>>> apogee
>>>>>>>>>> iOS
>>>>>>>>>>> sdks ,
>>>>>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or
>> RESTKit
>>>>>>>> which
>>>>>>>>>>> its self is build on AFNetworking, IM happy to put the time into this and I can spare one
>>>>>>> staff
>>>>>>>>>>> member to help me but I don’t want t start
>>>>>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love
>>>>> some
>>>>>>>>>> feed
>>>>>>>>>>> back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>>>>>>>>>> 
>>>>>>>>>>> 1- I think it should be package managed from the start. — CocoaPods
>>>>>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there
>> are
>>>>>>>>> plenty
>>>>>>>>>>> of good networking libraries at are well supported that will handle networking better .
>>>>>>>>>>> 3- I should be easy to extend easy to add new collection model classes.
>>>>>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.
>>>>>>>>>>> 5- Be fun to use..
>>>>>>>>>>> 
>>>>>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to
>>>>>> follow.
>>>>>>>>>>> these Idea are just mine if this is not what every one whats then I’ll go along with
>> whats
>>>>>>>>>> decided
>>>>>>>>>>> .
>>>>>>>>>>> 
>>>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>>>>> ph: +61 075699 8109
>>>>>>>>>>> mob: +61 0411 389 392
>>>>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>
>>>>>>>>>>> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>


Re: new iOS SDK

Posted by ja...@apps4u.com.au.
Diagram of network layer its not the class map but just a flow diagram of how I propose the network layer works

November 19 2014 4:38 PM, "Jason Kristian" <ja...@apps4u.com.au> wrote: 
> Base Class. eg: Usergrid
> One main Base Class that will be responsible for
> Org and App name init.
> Login
> Oauth 2 (get token stash it and use in http header).
> Push Messaging registration
> One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once .
> Block based async call backs. The base class will also be able to vend a http client to make http
> calls. As most applications will be interacting with other online api’s other than Usergrid so
> instead of making the user use some other network library and to make managing bandwidth better.
> The SDK will have a Session manager should take care of all request and manage and create
> NSURLSessions. So the SDK will manage two NSURLSession objects one for interacting with Usergrid
> and have the correct headers (token) and a 2nd session to work with other api so when I ask for the
> http client the sdk will configure a default NSURLSession or I can pass in a
> NSURLSessionConfiguration object which will let the SDK create a session and pass me a http client.
> Which will let the user set priority levels on requests and have a better user experience for the
> customer by having a responsive UI.
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
>> On 19 Nov 2014, at 4:25 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>> 
>> HI Ive added this to the Google Doc on the iOS SDK proposal . This is just the start so I’ll
> create
>> a class diagram using mind maps but I think I’ve covered the most important bits let me know if
>> I’ve missed anything please. As they say two heads are better then one.
>> 
>> Base Class. eg: Usergrid
>> One main Base Class that will be responsible for
>> Org and App name init.
>> Login
>> Oauth 2 (get token stash it and use in http header).
>> Push Messaging registration
>> One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once
> .
>> Block based async call backs. The base class will also be able to vend a http client to make http
>> calls. As most applications will be interacting with other online api’s other than Usergrid so
>> instead of making the user use some other network library and to make managing bandwidth better.
>> The one Session manager should take care of all request so I might have two NSURLSession objects
>> one for interacting with Usergrid and have the correct headers (token) and a 2nd session manager
> to
>> work with so other api which will let the user set priority level on requests and have a better
>> user experience for the customer.
>> 
>> Base Model eg: BaseEntity
>> Base Model object class. Now I like the model to be responsible for CRUD like operations now some
>> people might balk at this but that because when its not done right it gives you bloated classes
> and
>> lots of repeated code but Objective-C has a design pattern to solve this issue. So each Model
> class
>> will have a http delegate so when I ask the User model to fetch based on a query it will pass the
>> query along to it http client delegate to make the http call and give me the response in a block.
>> So when using this SDK I can create a subclass of the base Entity and the min I would need to do
> it
>> set its type property so when asking the custom model to fetch or save data it can pass the type
>> string to the HTTP delegate to know which uri to access. This also fits in with MVC pattern of
>> Objective-c iOS applications.
>> 
>> Now when a response returns more than one entity it give you a collection object , which will map
>> well into swift which will have typed collections. which will be a array Controller subclass.
>> 
>> So Usergrid Collections will not need a class its all wrapped up in the model object either a
>> single entity or collection of entities.
>> 
>> creating a new Usergrid collection will just require the saving of a entity of a new collection
>> type.
>> 
>> I think it should abstract away the network layer for working with models object that way only
> the
>> users that want to interact with the network layer have too eg: [User getByQuery:@”select where
>> name=’tim’”]; [User save:dictionary]; [User create:dictionary];
>> 
>> Cache Object.
>> There will be a cache that the user can enable and set timeout on. For example each requests
>> response can be cached at the network layer using a HTTP cache or we can just serialize the json
>> response to disk as either a json file or plist file using a NSEncoder. This solves the issue of
>> off line use and is a lot easier to implement than core data and is cheap in resources and easy
> to
>> throw away and rebuild and does not require the User to be an expert in objective-c as Core data
>> take time to master and lots of iOS developers don't know how to use it well , I’ve been
>> programming on Mac OS X since before the iPhone came out and I still learn new things about Core
>> Data.
>> 
>> Events and Counters. (logging??)
>> The counter api should be easy to use so UI controls should have categories that log their use
> and
>> the counter api should do most of UI event tracking without users of the sdk having to do
> anything
>> now if they want custom counter then they can create one but it should tack ui event for you .
> This
>> will require the sdk to setup some custom counters. It can get the tag of a UI control so if you
>> have a special button that you want to track and set the tag on it so it can be queried latter. I
>> think that there should be some remote logging that can be turn on that either send to a
> collection
>> or add a url endpoint to Usergrid. just basic logs (like Testflight remote log’s).
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <ma...@apps4u.com.au>
>> 
>>> On 19 Nov 2014, at 5:34 am, Rod Simpson <ro...@rodsimpson.com> wrote:
>>> 
>>> Good stuff! Sounds like you have a good handle on the use-cases that are specific to iOS. I have
>>> only built one app with iOS so can’t give as much input on that platform specifically. I am
>> really
>>> looking forward to what you come up with!
>>> 
>>> Rod
>>> 
>>> --
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com
>>> 
>>> On November 17, 2014 at 9:47:58 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>> 
>>> Thanks for feed back
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>> ph: +61 075699 8109
>>> mob: +61 0411 389 392
>>> e: Jason Kristian <ma...@apps4u.com.au>
>>> 
>>>> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>> 
>>>> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I
>>> wanted
>>>> to tackle this SDK after I’d did the PHP version , To take paging as one example I would give
>>> users
>>>> both options where there is a easy Iterator type method that can say page in lots of 20 for a
>>>> UITable view but if you have some custom UICollectionView and you want to handle paging your
>> self
>>>> then you can just pass the cursor along for you next call(page)
>>>> As with Models Object . I have two ways or more to deal with them for example some people like
>> be
>>>> able to ask the model for data and let it do the REST call behind the scenes for them other
>>> people
>>>> like making the API call and just getting back model objects so this is one of the reason I
>>> wanted
>>>> to start this to get every ones input as there is a log of decisions to be made and I did't
> want
>>> to
>>>> make them all my self as per my preferences.
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>> ph: +61 075699 8109
>>>> mob: +61 0411 389 392
>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>> 
>>>>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
> wrote:
>>>>> 
>>>>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl). Jason, I know
>>> you
>>>>> have already been through this with PHP, but since you are spurring this really awesome
>>>> discussion,
>>>>> I thought I would throw in some thoughts. I added this copy to the doc, but pasting it here
> for
>>>>> general review.
>>>>> 
>>>>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API
>>> is
>>>>> big and full featured and there are a few inconsistencies which can create landmines.
>>>>> 
>>>>> I think the first thing is to decide how you will keep track of “management” type features
> such
>>>> as
>>>>> logins. Do these go in a user entity object? Do they go in a client object? Where do you keep
>>>> track
>>>>> of the current token or client secret/id that will need to be sent along with every call? They
>>>>> “belong” to the user, but they are used for every API call.
>>>>> 
>>>>> Also, should the SDK have higher level constructs (objects) that model the way the data is
>>> stored
>>>>> on the server (e.g. collection, entity)? We did this in the Javascript and Node.js SDKs. These
>>>>> enable a bit more abstraction and may make it easier to use.
>>>>> 
>>>>> The problem is that not all the collections behave the same way. For example, the Users
>>>> collection
>>>>> uses “username” has a primary key, whereas groups use “path”, and custom collections use
>> “name”.
>>>> So
>>>>> one could create a base entity / collection class, then extending it to map to the different
>>>> types
>>>>> of entities / collections - built in, and custom. In the JS SDK, the collection objects hold a
>>>> set
>>>>> of entity objects that correspond to the current result set.
>>>>> 
>>>>> Another problem we ran into on the JS SDK is paging. Usergrid uses the concept of a cursor for
>>>>> result sets that have more than one “page” of data. By default, a page is 10 entities, but it
>>> can
>>>>> easily be extended to any number up to 1000. So what you do is make a call with your query,
>>> which
>>>>> then gives you back 10 entities and a cursor to get the next 10. You pass that cursor along
>> with
>>>>> the next call, which will give you back the next 10 and a cursor. Repeat until you get to the
>>> end
>>>>> of the result set. Most apps need to use paging to show results since you generally don’t want
>>> to
>>>>> pull down 1000 entities every time. In the JS SDK, we did something like this:
>>>>> 
>>>>> var books;
>>>>> 
>>>>> client.createCollection(options, function (err, collection) {
>>>>> books = collection;
>>>>> if (err) {
>>>>> alert("Couldn't get the list of books.");
>>>>> } else {
>>>>> while(books.hasNextEntity()) {
>>>>> var book = books.getNextEntity();
>>>>> alert(book.get("title")); // Output the title of the book
>>>>> }
>>>>> }
>>>>> });
>>>>> 
>>>>> So the client has a factory method that hands back a collection. Then, you can simply call
>>>>> getNextEntity on the object to loop through the current page of data. If you want to iterate
>>>>> through pages, you can use the getNextPage method:
>>>>> 
>>>>> if (dogs.hasNextPage()) {
>>>>> // There is a next page, so get it from the server
>>>>> dogs.getNextPage(function(err){
>>>>> if (err) {
>>>>> // Error - could not get next page of dogs
>>>>> } else {
>>>>> // Success - got next page of dogs, so do something with it
>>>>> while(dogs.hasNextEntity()) {
>>>>> // Get a reference to the dog
>>>>> dog = dogs.getNextEntity();
>>>>> // Do something with the entity
>>>>> var name = dog.get('name');
>>>>> }
>>>>> }
>>>>> });
>>>>> }
>>>>> 
>>>>> It took some doing to make sure that the logic for paging was sound, because the result sets
>>>> don’t
>>>>> give you back a cursor for the previous page - only the next page. So you have to hang onto
>> them
>>>>> and build a stack.
>>>>> 
>>>>> I’m not saying this needs to be done this way, just something to think about.
>>>>> 
>>>>> --
>>>>> Rod Simpson
>>>>> @rockerston
>>>>> rodsimpson.com <http://rodsimpson.com/>
>>>>> 
>>>>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>>>> 
>>>>> HI to all Ive now made sure that the Google doc has got read / write access when opening with
>>>> that
>>>>> link . It would be good if any one had input to speak up now as this will be a better SDK when
>>>> all
>>>>> the Usergrid comunity has input so every idea and most users needs can be catered for. I was
>>>> hoping
>>>>> to get the design done by the end of this week so I can start on this the last week of
> November
>>>>> which should let me get it done hopefully just before Christmas.
>>>>> 
>>>>> Thanks add you input the proposal doc.
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>> ph: +61 075699 8109
>>>>> mob: +61 0411 389 392
>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>> 
>>>>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>> 
>>>>>> this link has edit permission
>>>>>> 
>>>>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>> ph: +61 075699 8109
>>>>>> mob: +61 0411 389 392
>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>> 
>>>>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>>> 
>>>>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will
>>>>>> contain
>>>>>>> UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.
>>>>>>> 
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>> ph: +61 075699 8109
>>>>>>> mob: +61 0411 389 392
>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>>> 
>>>>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
>>>> wrote:
>>>>>>>> 
>>>>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned
> is
>>>>>> Unit
>>>>>>> /
>>>>>>>> e2e tests. It would be great if we were designing those from the start. Also, samples. It
>>>> would
>>>>>>> be
>>>>>>>> awesome if we had some samples - especially for the get-up-and-going things.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Rod Simpson
>>>>>>>> @rockerston
>>>>>>>> rodsimpson.com <http://rodsimpson.com/>
>>>>>>>> 
>>>>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:
>>>>>>>> 
>>>>>>>> Jason,
>>>>>>>> 
>>>>>>>> Nice way to start this out!
>>>>>>>> 
>>>>>>>> 
>>>>> 
>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>>>> 
>>>>>>>> I am reviewing now.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Rod Simpson
>>>>>>>> @rockerston
>>>>>>>> rodsimpson.com
>>>>>>>> 
>>>>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>>>>>>> 
>>>>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or
>>>>> suggestions
>>>>>>>> gave the input as the more input we have the better the end result.
>>>>>>>> 
>>>>>>>> 
>>>>> 
>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>>>>>>> 
>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>> ph: +61 075699 8109
>>>>>>>> mob: +61 0411 389 392
>>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>
>>>>>>>> 
>>>>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>>>>>>> 
>>>>>>>>> Cool ,
>>>>>>>>> 
>>>>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid
>>>>> community)
>>>>>>>> can
>>>>>>>>> se. Like for example license , stable is it going to be around , etc.
>>>>>>>>> 
>>>>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that
>>>> the
>>>>>>>> SDK
>>>>>>>>> be open to use other libraries for just that reason JSON, Network, etc.
>>>>>>>>> 
>>>>>>>>> What I really would like to do is put together a proposal and then have the community
>>> comment
>>>>> ,
>>>>>>>>> edit , add ideas to its so we can have a plan and set some guideline for example the usage
>>> of
>>>>>>> 3rd
>>>>>>>>> party Libraries.
>>>>>>>>> 
>>>>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I
>>> think
>>>>>> we
>>>>>>>>> should take the approach that it be modular and extendable . All of us that Usergrid in
>>>>>>>> commercial
>>>>>>>>> way have all added Api to Usergrid itself or through some Node JS reverse proxy and it
>> would
>>>>> be
>>>>>>>>> good if it was easy to make http calls to custom endpoints using that same SDK.
>>>>>>>>> 
>>>>>>>>> I was look at where I could create this proposal document . I was thinking I use Google
>>> doc’s
>>>>>>> and
>>>>>>>>> send to mailing list or is there a places where I could create a proposal document.
>>>>>>>>> 
>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>>> ph: +61 075699 8109
>>>>>>>>> mob: +61 0411 389 392
>>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>>>>>>>>> 
>>>>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>>
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Jason,
>>>>>>>>>> 
>>>>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work
>>>> from
>>>>>>>> the
>>>>>>>>>> Apigee SDK. That codebase is quite old and is definitely not the way we would architect
> it
>>>>>> from
>>>>>>>>>> scratch today.
>>>>>>>>>> 
>>>>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be
>>>>>> mindful
>>>>>>>>> of
>>>>>>>>>> their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is
>> perfect.
>>>>>>>>>> 
>>>>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing
> in
>>>>> the
>>>>>>>>>> current iOS SDK. At one point, there was some work done with Lua to create a little
>>>> framework
>>>>>>>> for
>>>>>>>>>> testing but it never really went anywhere. Having guardrails in place from the start
> would
>>>>>> make
>>>>>>>>> it
>>>>>>>>>> a lot easier for other developers to get in and help work on the project.
>>>>>>>>>> 
>>>>>>>>>> #4, interoperation with Swift would be great.
>>>>>>>>>> 
>>>>>>>>>> What are you thinking about for handling JSON?
>>>>>>>>>> 
>>>>>>>>>> And of course, #5 would be icing on the cake :)
>>>>>>>>>> 
>>>>>>>>>> Rod
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Rod Simpson
>>>>>>>>>> @rockerston
>>>>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>>>>>>>>> 
>>>>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au
>>>>>>>>>> <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au
> <ma...@apps4u.com.au>>)
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now
>>>> there
>>>>>>>> are
>>>>>>>>> a
>>>>>>>>>> few options on what can be done for example with could build on the current SDK or fork
>>>>> apogee
>>>>>>>>> iOS
>>>>>>>>>> sdks ,
>>>>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or
> RESTKit
>>>>>>> which
>>>>>>>>>> its self is build on AFNetworking, IM happy to put the time into this and I can spare one
>>>>>> staff
>>>>>>>>>> member to help me but I don’t want t start
>>>>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love
>>>> some
>>>>>>>>> feed
>>>>>>>>>> back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>>>>>>>>> 
>>>>>>>>>> 1- I think it should be package managed from the start. — CocoaPods
>>>>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there
> are
>>>>>>>> plenty
>>>>>>>>>> of good networking libraries at are well supported that will handle networking better .
>>>>>>>>>> 3- I should be easy to extend easy to add new collection model classes.
>>>>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.
>>>>>>>>>> 5- Be fun to use..
>>>>>>>>>> 
>>>>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to
>>>>> follow.
>>>>>>>>>> these Idea are just mine if this is not what every one whats then I’ll go along with
> whats
>>>>>>>>> decided
>>>>>>>>>> .
>>>>>>>>>> 
>>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>>>>>>> ph: +61 075699 8109
>>>>>>>>>> mob: +61 0411 389 392
>>>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>
>>>>>>>>>> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>

Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
Base Class. eg: Usergrid
One main Base Class that will be responsible for 
Org and App name init.
Login
Oauth 2 (get token stash it and use in http header).
Push Messaging registration
One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once . Block based async call backs. The base class will also be able to vend a http client to make http calls. As most applications will be interacting with other online api’s other than Usergrid so instead of making the user use some other network library and to make managing bandwidth better. The SDK will have a  Session manager should take care of all request and manage and create NSURLSessions. So the SDK will manage two NSURLSession objects one for interacting with Usergrid and have the correct headers (token) and a 2nd session to work with other api so when I ask for the http client the sdk will configure a default NSURLSession or I can pass in a NSURLSessionConfiguration object which will let the SDK create a session and pass me a http client.  Which will let the user set priority levels on requests and have a better user experience for the customer by having a responsive UI. 


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 19 Nov 2014, at 4:25 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
> 
> HI Ive added this to the Google Doc on the iOS SDK proposal . This is just the start so I’ll create a class diagram using mind maps but I think I’ve covered the most important bits let me know if I’ve missed anything please. As they say two heads are better then one.
> 
> 
> Base Class. eg: Usergrid
> One main Base Class that will be responsible for 
> Org and App name init.
> Login
> Oauth 2 (get token stash it and use in http header).
> Push Messaging registration
> One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once . Block based async call backs. The base class will also be able to vend a http client to make http calls. As most applications will be interacting with other online api’s other than Usergrid so instead of making the user use some other network library and to make managing bandwidth better. The one Session manager should take care of all request so I might have two NSURLSession objects one for interacting with Usergrid and have the correct headers (token) and a 2nd session manager to work with so other api which will let the user set priority level on requests and have a better user experience for the customer.
> 
> Base Model eg: BaseEntity
> Base Model object class. Now I like the model to be responsible for CRUD like operations now some people might balk at this but that because when its not done right it gives you bloated classes and lots of repeated code but Objective-C has a design pattern to solve this issue. So each Model class will have a http delegate so when I ask the User model to fetch based on a query it will pass the query along to it http client delegate to make the http call and give me the response in a block. So when using this SDK I can create a subclass of the base Entity and the min I would need to do it set its type property so when asking the custom model to fetch or save data it can pass the type string to the HTTP delegate to know which uri to access.  This also fits in with MVC pattern of Objective-c iOS applications.
> 
> Now when a response returns more than one entity it give you a collection object , which will map well into swift which will have typed collections. which will be a array Controller subclass.
> 
> So Usergrid Collections will not need a class its all wrapped up in the model object either a single entity or collection of entities.
> 
> creating a new Usergrid collection will just require the saving of a entity of a new collection type.
> 
> I think it should abstract away the network layer for working with models object that way only the users that want to interact with the network layer have too eg: [User getByQuery:@”select where name=’tim’”];  [User save:dictionary]; [User create:dictionary];
> 
> Cache Object.
> There will be a cache that the user can enable and set timeout on. For example each requests response can be cached at the network layer using a HTTP cache or we can just serialize the json response to disk as either a json file or plist file using a NSEncoder.  This solves the issue of off line use and is a lot easier to implement than core data and is cheap in resources and easy to throw away and rebuild and does not require the User to be an expert in objective-c as Core data take time to master and lots of iOS developers don't know how to use it well , I’ve been programming on Mac OS X since before the iPhone came out and I still learn new things about Core Data.
> 
> Events and Counters. (logging??)
> The counter api should be easy to use so UI controls should have categories that log their use and the counter api should do most of UI event tracking without users of the sdk having to do anything now if they want custom counter then they can create one but it should tack ui event for you . This will require the sdk to setup some custom counters. It can get the tag of a UI control so if you have a special button that you want to track and set the tag on it so it can be queried latter. I think that there should be some remote logging that can be turn on that either send to a collection or add a url endpoint to Usergrid. just basic logs (like Testflight remote log’s). 
> 
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
> 
> 
>> On 19 Nov 2014, at 5:34 am, Rod Simpson <ro...@rodsimpson.com> wrote:
>> 
>> Good stuff!  Sounds like you have a good handle on the use-cases that are specific to iOS.  I have only built one app with iOS so can’t give as much input on that platform specifically.  I am really looking forward to what you come up with!
>> 
>> Rod  
>> 
>> 
>> 
>> -- 
>> Rod Simpson
>> @rockerston
>> rodsimpson.com
>> 
>> On November 17, 2014 at 9:47:58 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>> 
>> Thanks for feed back  
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>> 
>> 
>> 
>>> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>> 
>>> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I wanted to tackle this SDK after I’d did the PHP version , To take paging as one example I would give users both options where there is a easy Iterator type method that can say page in lots of 20 for a UITable view but if you have some custom UICollectionView and you want to handle paging your self then you can just pass the cursor along for you next call(page)  
>>> As with Models Object . I have two ways or more to deal with them for example some people like be able to ask the model for data and let it do the REST call behind the scenes for them other people like making the API call and just getting back model objects so this is one of the reason I wanted to start this to get every ones input as there is a log of decisions to be made and I did't want to make them all my self as per my preferences.  
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>> 
>>> 
>>> 
>>>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>> 
>>>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl). Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts. I added this copy to the doc, but pasting it here for general review.  
>>>> 
>>>> 
>>>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  
>>>> 
>>>> I think the first thing is to decide how you will keep track of “management” type features such as logins. Do these go in a user entity object? Do they go in a client object? Where do you keep track of the current token or client secret/id that will need to be sent along with every call? They “belong” to the user, but they are used for every API call.  
>>>> 
>>>> Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)? We did this in the Javascript and Node.js SDKs. These enable a bit more abstraction and may make it easier to use.  
>>>> 
>>>> The problem is that not all the collections behave the same way. For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”. So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom. In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.  
>>>> 
>>>> Another problem we ran into on the JS SDK is paging. Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000. So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10. You pass that cursor along with the next call, which will give you back the next 10 and a cursor. Repeat until you get to the end of the result set. Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time. In the JS SDK, we did something like this:  
>>>> 
>>>> var books;  
>>>> 
>>>> client.createCollection(options, function (err, collection) {  
>>>> books = collection;  
>>>> if (err) {  
>>>> alert("Couldn't get the list of books.");  
>>>> } else {  
>>>> while(books.hasNextEntity()) {  
>>>> var book = books.getNextEntity();  
>>>> alert(book.get("title")); // Output the title of the book  
>>>> }  
>>>> }  
>>>> });  
>>>> 
>>>> 
>>>> So the client has a factory method that hands back a collection. Then, you can simply call getNextEntity on the object to loop through the current page of data. If you want to iterate through pages, you can use the getNextPage method:  
>>>> 
>>>> if (dogs.hasNextPage()) {  
>>>> // There is a next page, so get it from the server  
>>>> dogs.getNextPage(function(err){  
>>>> if (err) {  
>>>> // Error - could not get next page of dogs  
>>>> } else {  
>>>> // Success - got next page of dogs, so do something with it  
>>>> while(dogs.hasNextEntity()) {  
>>>> // Get a reference to the dog  
>>>> dog = dogs.getNextEntity();  
>>>> // Do something with the entity  
>>>> var name = dog.get('name');  
>>>> }  
>>>> }  
>>>> });  
>>>> }  
>>>> 
>>>> It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  
>>>> 
>>>> I’m not saying this needs to be done this way, just something to think about.  
>>>> 
>>>> 
>>>> 
>>>> --  
>>>> Rod Simpson  
>>>> @rockerston  
>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>> 
>>>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>> 
>>>> HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  
>>>> 
>>>> Thanks add you input the proposal doc.  
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>> 
>>>> 
>>>> 
>>>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>> 
>>>>> this link has edit permission  
>>>>> 
>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>>>>> 
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>>> 
>>>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>> ph: +61 075699 8109  
>>>>>> mob: +61 0411 389 392  
>>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>>> 
>>>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>>>>> 
>>>>>>> Thanks!  
>>>>>>> 
>>>>>>> 
>>>>>>> --  
>>>>>>> Rod Simpson  
>>>>>>> @rockerston  
>>>>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>>>>> 
>>>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>>>>> 
>>>>>>> Jason,  
>>>>>>> 
>>>>>>> Nice way to start this out!  
>>>>>>> 
>>>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>>> 
>>>>>>> I am reviewing now.  
>>>>>>> 
>>>>>>> 
>>>>>>> --  
>>>>>>> Rod Simpson  
>>>>>>> @rockerston  
>>>>>>> rodsimpson.com  
>>>>>>> 
>>>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>>>>> 
>>>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>>>>> 
>>>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>>> 
>>>>>>> 
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>> ph: +61 075699 8109  
>>>>>>> mob: +61 0411 389 392  
>>>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>>>>> 
>>>>>>>> Cool ,  
>>>>>>>> 
>>>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>>>>> 
>>>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>>>>> 
>>>>>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>>>>> 
>>>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>>>>> 
>>>>>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>>> ph: +61 075699 8109  
>>>>>>>> mob: +61 0411 389 392  
>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>>>>> 
>>>>>>>>> Jason,  
>>>>>>>>> 
>>>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>>>>> 
>>>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>>>>> 
>>>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>>>>> 
>>>>>>>>> #4, interoperation with Swift would be great.  
>>>>>>>>> 
>>>>>>>>> What are you thinking about for handling JSON?  
>>>>>>>>> 
>>>>>>>>> And of course, #5 would be icing on the cake :)  
>>>>>>>>> 
>>>>>>>>> Rod  
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --  
>>>>>>>>> Rod Simpson  
>>>>>>>>> @rockerston  
>>>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>>>>> 
>>>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>>>>> 
>>>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>>>>> 
>>>>>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>>>>>> 5- Be fun to use..  
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>>>> ph: +61 075699 8109  
>>>>>>>>> mob: +61 0411 389 392  
>>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
 HI Ive added this to the Google Doc on the iOS SDK proposal . This is just the start so I’ll create a class diagram using mind maps but I think I’ve covered the most important bits let me know if I’ve missed anything please. As they say two heads are better then one.


Base Class. eg: Usergrid
One main Base Class that will be responsible for 
Org and App name init.
Login
Oauth 2 (get token stash it and use in http header).
Push Messaging registration
One Main HTTP Client that is based on NSURLSession so it can have many requests in flight as once . Block based async call backs. The base class will also be able to vend a http client to make http calls. As most applications will be interacting with other online api’s other than Usergrid so instead of making the user use some other network library and to make managing bandwidth better. The one Session manager should take care of all request so I might have two NSURLSession objects one for interacting with Usergrid and have the correct headers (token) and a 2nd session manager to work with so other api which will let the user set priority level on requests and have a better user experience for the customer.
 
Base Model eg: BaseEntity
Base Model object class. Now I like the model to be responsible for CRUD like operations now some people might balk at this but that because when its not done right it gives you bloated classes and lots of repeated code but Objective-C has a design pattern to solve this issue. So each Model class will have a http delegate so when I ask the User model to fetch based on a query it will pass the query along to it http client delegate to make the http call and give me the response in a block. So when using this SDK I can create a subclass of the base Entity and the min I would need to do it set its type property so when asking the custom model to fetch or save data it can pass the type string to the HTTP delegate to know which uri to access.  This also fits in with MVC pattern of Objective-c iOS applications.

Now when a response returns more than one entity it give you a collection object , which will map well into swift which will have typed collections. which will be a array Controller subclass.

So Usergrid Collections will not need a class its all wrapped up in the model object either a single entity or collection of entities.

creating a new Usergrid collection will just require the saving of a entity of a new collection type.

I think it should abstract away the network layer for working with models object that way only the users that want to interact with the network layer have too eg: [User getByQuery:@”select where name=’tim’”];  [User save:dictionary]; [User create:dictionary];

Cache Object.
There will be a cache that the user can enable and set timeout on. For example each requests response can be cached at the network layer using a HTTP cache or we can just serialize the json response to disk as either a json file or plist file using a NSEncoder.  This solves the issue of off line use and is a lot easier to implement than core data and is cheap in resources and easy to throw away and rebuild and does not require the User to be an expert in objective-c as Core data take time to master and lots of iOS developers don't know how to use it well , I’ve been programming on Mac OS X since before the iPhone came out and I still learn new things about Core Data.

Events and Counters. (logging??)
The counter api should be easy to use so UI controls should have categories that log their use and the counter api should do most of UI event tracking without users of the sdk having to do anything now if they want custom counter then they can create one but it should tack ui event for you . This will require the sdk to setup some custom counters. It can get the tag of a UI control so if you have a special button that you want to track and set the tag on it so it can be queried latter. I think that there should be some remote logging that can be turn on that either send to a collection or add a url endpoint to Usergrid. just basic logs (like Testflight remote log’s). 


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 19 Nov 2014, at 5:34 am, Rod Simpson <ro...@rodsimpson.com> wrote:
> 
> Good stuff!  Sounds like you have a good handle on the use-cases that are specific to iOS.  I have only built one app with iOS so can’t give as much input on that platform specifically.  I am really looking forward to what you come up with!
> 
> Rod  
> 
> 
> 
> -- 
> Rod Simpson
> @rockerston
> rodsimpson.com
> 
> On November 17, 2014 at 9:47:58 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
> 
> Thanks for feed back  
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <ma...@apps4u.com.au>  
> 
> 
> 
>> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>> 
>> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I wanted to tackle this SDK after I’d did the PHP version , To take paging as one example I would give users both options where there is a easy Iterator type method that can say page in lots of 20 for a UITable view but if you have some custom UICollectionView and you want to handle paging your self then you can just pass the cursor along for you next call(page)  
>> As with Models Object . I have two ways or more to deal with them for example some people like be able to ask the model for data and let it do the REST call behind the scenes for them other people like making the API call and just getting back model objects so this is one of the reason I wanted to start this to get every ones input as there is a log of decisions to be made and I did't want to make them all my self as per my preferences.  
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>> 
>> 
>> 
>>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>> 
>>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl). Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts. I added this copy to the doc, but pasting it here for general review.  
>>> 
>>> 
>>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  
>>> 
>>> I think the first thing is to decide how you will keep track of “management” type features such as logins. Do these go in a user entity object? Do they go in a client object? Where do you keep track of the current token or client secret/id that will need to be sent along with every call? They “belong” to the user, but they are used for every API call.  
>>> 
>>> Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)? We did this in the Javascript and Node.js SDKs. These enable a bit more abstraction and may make it easier to use.  
>>> 
>>> The problem is that not all the collections behave the same way. For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”. So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom. In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.  
>>> 
>>> Another problem we ran into on the JS SDK is paging. Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000. So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10. You pass that cursor along with the next call, which will give you back the next 10 and a cursor. Repeat until you get to the end of the result set. Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time. In the JS SDK, we did something like this:  
>>> 
>>> var books;  
>>> 
>>> client.createCollection(options, function (err, collection) {  
>>> books = collection;  
>>> if (err) {  
>>> alert("Couldn't get the list of books.");  
>>> } else {  
>>> while(books.hasNextEntity()) {  
>>> var book = books.getNextEntity();  
>>> alert(book.get("title")); // Output the title of the book  
>>> }  
>>> }  
>>> });  
>>> 
>>> 
>>> So the client has a factory method that hands back a collection. Then, you can simply call getNextEntity on the object to loop through the current page of data. If you want to iterate through pages, you can use the getNextPage method:  
>>> 
>>> if (dogs.hasNextPage()) {  
>>> // There is a next page, so get it from the server  
>>> dogs.getNextPage(function(err){  
>>> if (err) {  
>>> // Error - could not get next page of dogs  
>>> } else {  
>>> // Success - got next page of dogs, so do something with it  
>>> while(dogs.hasNextEntity()) {  
>>> // Get a reference to the dog  
>>> dog = dogs.getNextEntity();  
>>> // Do something with the entity  
>>> var name = dog.get('name');  
>>> }  
>>> }  
>>> });  
>>> }  
>>> 
>>> It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  
>>> 
>>> I’m not saying this needs to be done this way, just something to think about.  
>>> 
>>> 
>>> 
>>> --  
>>> Rod Simpson  
>>> @rockerston  
>>> rodsimpson.com <http://rodsimpson.com/>  
>>> 
>>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>> 
>>> HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  
>>> 
>>> Thanks add you input the proposal doc.  
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>> 
>>> 
>>> 
>>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>> 
>>>> this link has edit permission  
>>>> 
>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>>>> 
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>> 
>>>> 
>>>> 
>>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>> 
>>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>> 
>>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>>>> 
>>>>>> Thanks!  
>>>>>> 
>>>>>> 
>>>>>> --  
>>>>>> Rod Simpson  
>>>>>> @rockerston  
>>>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>>>> 
>>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>>>> 
>>>>>> Jason,  
>>>>>> 
>>>>>> Nice way to start this out!  
>>>>>> 
>>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>> 
>>>>>> I am reviewing now.  
>>>>>> 
>>>>>> 
>>>>>> --  
>>>>>> Rod Simpson  
>>>>>> @rockerston  
>>>>>> rodsimpson.com  
>>>>>> 
>>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>>>> 
>>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>>>> 
>>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>> 
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>> ph: +61 075699 8109  
>>>>>> mob: +61 0411 389 392  
>>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>>>> 
>>>>>>> Cool ,  
>>>>>>> 
>>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>>>> 
>>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>>>> 
>>>>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>>>> 
>>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>>>> 
>>>>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>>>> 
>>>>>>> 
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>> ph: +61 075699 8109  
>>>>>>> mob: +61 0411 389 392  
>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>>>> 
>>>>>>>> Jason,  
>>>>>>>> 
>>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>>>> 
>>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>>>> 
>>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>>>> 
>>>>>>>> #4, interoperation with Swift would be great.  
>>>>>>>> 
>>>>>>>> What are you thinking about for handling JSON?  
>>>>>>>> 
>>>>>>>> And of course, #5 would be icing on the cake :)  
>>>>>>>> 
>>>>>>>> Rod  
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --  
>>>>>>>> Rod Simpson  
>>>>>>>> @rockerston  
>>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>>>> 
>>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>>>> 
>>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>>>> 
>>>>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>>>>> 5- Be fun to use..  
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>>> ph: +61 075699 8109  
>>>>>>>> mob: +61 0411 389 392  
>>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
Good stuff!  Sounds like you have a good handle on the use-cases that are specific to iOS.  I have only built one app with iOS so can’t give as much input on that platform specifically.  I am really looking forward to what you come up with!

Rod  



-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 17, 2014 at 9:47:58 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:

Thanks for feed back  

Jason Kristian | Director | Apps 4 U Pty Ltd.  
ph: +61 075699 8109  
mob: +61 0411 389 392  
e: Jason Kristian <ma...@apps4u.com.au>  



> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>  
> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I wanted to tackle this SDK after I’d did the PHP version , To take paging as one example I would give users both options where there is a easy Iterator type method that can say page in lots of 20 for a UITable view but if you have some custom UICollectionView and you want to handle paging your self then you can just pass the cursor along for you next call(page)  
> As with Models Object . I have two ways or more to deal with them for example some people like be able to ask the model for data and let it do the REST call behind the scenes for them other people like making the API call and just getting back model objects so this is one of the reason I wanted to start this to get every ones input as there is a log of decisions to be made and I did't want to make them all my self as per my preferences.  
>  
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <ma...@apps4u.com.au>  
>  
>  
>  
>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>  
>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl). Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts. I added this copy to the doc, but pasting it here for general review.  
>>  
>>  
>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  
>>  
>> I think the first thing is to decide how you will keep track of “management” type features such as logins. Do these go in a user entity object? Do they go in a client object? Where do you keep track of the current token or client secret/id that will need to be sent along with every call? They “belong” to the user, but they are used for every API call.  
>>  
>> Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)? We did this in the Javascript and Node.js SDKs. These enable a bit more abstraction and may make it easier to use.  
>>  
>> The problem is that not all the collections behave the same way. For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”. So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom. In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.  
>>  
>> Another problem we ran into on the JS SDK is paging. Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000. So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10. You pass that cursor along with the next call, which will give you back the next 10 and a cursor. Repeat until you get to the end of the result set. Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time. In the JS SDK, we did something like this:  
>>  
>> var books;  
>>  
>> client.createCollection(options, function (err, collection) {  
>> books = collection;  
>> if (err) {  
>> alert("Couldn't get the list of books.");  
>> } else {  
>> while(books.hasNextEntity()) {  
>> var book = books.getNextEntity();  
>> alert(book.get("title")); // Output the title of the book  
>> }  
>> }  
>> });  
>>  
>>  
>> So the client has a factory method that hands back a collection. Then, you can simply call getNextEntity on the object to loop through the current page of data. If you want to iterate through pages, you can use the getNextPage method:  
>>  
>> if (dogs.hasNextPage()) {  
>> // There is a next page, so get it from the server  
>> dogs.getNextPage(function(err){  
>> if (err) {  
>> // Error - could not get next page of dogs  
>> } else {  
>> // Success - got next page of dogs, so do something with it  
>> while(dogs.hasNextEntity()) {  
>> // Get a reference to the dog  
>> dog = dogs.getNextEntity();  
>> // Do something with the entity  
>> var name = dog.get('name');  
>> }  
>> }  
>> });  
>> }  
>>  
>> It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  
>>  
>> I’m not saying this needs to be done this way, just something to think about.  
>>  
>>  
>>  
>> --  
>> Rod Simpson  
>> @rockerston  
>> rodsimpson.com <http://rodsimpson.com/>  
>>  
>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>  
>> HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  
>>  
>> Thanks add you input the proposal doc.  
>>  
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>>  
>>  
>>  
>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>  
>>> this link has edit permission  
>>>  
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>>>  
>>>  
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>  
>>>  
>>>  
>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>  
>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>>>  
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>  
>>>>  
>>>>  
>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>  
>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>>>  
>>>>> Thanks!  
>>>>>  
>>>>>  
>>>>> --  
>>>>> Rod Simpson  
>>>>> @rockerston  
>>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>>>  
>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>>>  
>>>>> Jason,  
>>>>>  
>>>>> Nice way to start this out!  
>>>>>  
>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>  
>>>>> I am reviewing now.  
>>>>>  
>>>>>  
>>>>> --  
>>>>> Rod Simpson  
>>>>> @rockerston  
>>>>> rodsimpson.com  
>>>>>  
>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>>>  
>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>>>  
>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>>  
>>>>>  
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>>  
>>>>>  
>>>>>  
>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>>>  
>>>>>> Cool ,  
>>>>>>  
>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>>>  
>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>>>  
>>>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>>>  
>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>>>  
>>>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>>>  
>>>>>>  
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>> ph: +61 075699 8109  
>>>>>> mob: +61 0411 389 392  
>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>>>  
>>>>>>> Jason,  
>>>>>>>  
>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>>>  
>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>>>  
>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>>>  
>>>>>>> #4, interoperation with Swift would be great.  
>>>>>>>  
>>>>>>> What are you thinking about for handling JSON?  
>>>>>>>  
>>>>>>> And of course, #5 would be icing on the cake :)  
>>>>>>>  
>>>>>>> Rod  
>>>>>>>  
>>>>>>>  
>>>>>>> --  
>>>>>>> Rod Simpson  
>>>>>>> @rockerston  
>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>>>  
>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>>>  
>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>>>  
>>>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>>>> 5- Be fun to use..  
>>>>>>>  
>>>>>>>  
>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>> ph: +61 075699 8109  
>>>>>>> mob: +61 0411 389 392  
>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>>>  
>>>>  
>>>  
>>  
>  


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
Thanks for feed back

Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 18 Nov 2014, at 2:43 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
> 
> I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I wanted to tackle this SDK after I’d did the PHP version ,  To take paging as one example I would give users both options where there is a easy Iterator type method that can say page in lots of 20 for a UITable view but if you have some custom UICollectionView and you want to handle paging your self then you can just pass the cursor along for you next call(page)
> As with Models Object . I have two ways or more to deal with them for example some people like be able to ask the model for data and let it do the REST call behind the scenes for them other people like making the API call and just getting back model objects so this is one of the reason I wanted to start this to get every ones input as there is a log of decisions to be made and I did't want to make them all my self as per my preferences.
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
> 
> 
>> On 18 Nov 2014, at 2:42 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>> 
>> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl).  Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts.  I added this copy to the doc, but pasting it here for general review. 
>> 
>> 
>> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  
>> 
>> I think the first thing is to decide how you will keep track of “management” type features such as logins.  Do these go in a user entity object?  Do they go in a client object?  Where do you keep track of the current token or client secret/id that will need to be sent along with every call?  They “belong” to the user, but they are used for every API call.  
>> 
>> Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)?  We did this in the Javascript and Node.js SDKs.  These enable a bit more abstraction and may make it easier to use.  
>> 
>> The problem is that not all the collections behave the same way.  For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”.  So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom.  In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.
>> 
>> Another problem we ran into on the JS SDK is paging.  Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000.  So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10.  You pass that cursor along with the next call, which will give you back the next 10 and a cursor.  Repeat until you get to the end of the result set.  Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time.  In the JS SDK, we did something like this:
>> 
>> var books;
>> 
>>            client.createCollection(options, function (err, collection) {
>>                books = collection;
>>                if (err) {
>>                    alert("Couldn't get the list of books.");
>>                } else {
>>                    while(books.hasNextEntity()) {
>>                        var book = books.getNextEntity();
>>                        alert(book.get("title")); // Output the title of the book
>>                    }
>>                }
>>            });
>> 
>> 
>> So the client has a factory method that hands back a collection.  Then, you can simply call getNextEntity on the object to loop through the current page of data.  If you want to iterate through pages, you can use the getNextPage method:
>> 
>> if (dogs.hasNextPage()) {
>>    // There is a next page, so get it from the server
>>    dogs.getNextPage(function(err){
>>        if (err) {
>>            // Error - could not get next page of dogs
>>        } else {
>>            // Success - got next page of dogs, so do something with it
>>            while(dogs.hasNextEntity()) {
>>                // Get a reference to the dog
>>                dog = dogs.getNextEntity();
>>                // Do something with the entity
>>                var name = dog.get('name');
>>            }
>>        }
>>    });
>> }
>> 
>> It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  
>> 
>> I’m not saying this needs to be done this way, just something to think about.  
>> 
>> 
>> 
>> -- 
>> Rod Simpson
>> @rockerston
>> rodsimpson.com <http://rodsimpson.com/>
>> 
>> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>> 
>> HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  
>> 
>> Thanks add you input the proposal doc.  
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>> 
>> 
>> 
>>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>> 
>>> this link has edit permission  
>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>>> 
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>> 
>>> 
>>> 
>>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>> 
>>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>> 
>>>> 
>>>> 
>>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>> 
>>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>>> 
>>>>> Thanks!  
>>>>> 
>>>>> 
>>>>> --  
>>>>> Rod Simpson  
>>>>> @rockerston  
>>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>>> 
>>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>>> 
>>>>> Jason,  
>>>>> 
>>>>> Nice way to start this out!  
>>>>> 
>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>> 
>>>>> I am reviewing now.  
>>>>> 
>>>>> 
>>>>> --  
>>>>> Rod Simpson  
>>>>> @rockerston  
>>>>> rodsimpson.com  
>>>>> 
>>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>>> 
>>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>>> 
>>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>>> 
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>>> 
>>>>>> Cool ,  
>>>>>> 
>>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>>> 
>>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>>> 
>>>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>>> 
>>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>>> 
>>>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>>> 
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>> ph: +61 075699 8109  
>>>>>> mob: +61 0411 389 392  
>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>>> 
>>>>>>> Jason,  
>>>>>>> 
>>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>>> 
>>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>>> 
>>>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>>> 
>>>>>>> #4, interoperation with Swift would be great.  
>>>>>>> 
>>>>>>> What are you thinking about for handling JSON?  
>>>>>>> 
>>>>>>> And of course, #5 would be icing on the cake :)  
>>>>>>> 
>>>>>>> Rod  
>>>>>>> 
>>>>>>> 
>>>>>>> --  
>>>>>>> Rod Simpson  
>>>>>>> @rockerston  
>>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>>> 
>>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>>> 
>>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>>> 
>>>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>>>> 5- Be fun to use..  
>>>>>>> 
>>>>>>> 
>>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>>> ph: +61 075699 8109  
>>>>>>> mob: +61 0411 389 392  
>>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>>> 
>>>> 
>>> 
>> 
> 


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
I agree with what you say, I’ve had a chance to deal with this in the PHP SDK which is why I wanted to tackle this SDK after I’d did the PHP version ,  To take paging as one example I would give users both options where there is a easy Iterator type method that can say page in lots of 20 for a UITable view but if you have some custom UICollectionView and you want to handle paging your self then you can just pass the cursor along for you next call(page)
As with Models Object . I have two ways or more to deal with them for example some people like be able to ask the model for data and let it do the REST call behind the scenes for them other people like making the API call and just getting back model objects so this is one of the reason I wanted to start this to get every ones input as there is a log of decisions to be made and I did't want to make them all my self as per my preferences.

Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 18 Nov 2014, at 2:42 am, Rod Simpson <ro...@rodsimpson.com> wrote:
> 
> Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl).  Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts.  I added this copy to the doc, but pasting it here for general review. 
> 
> 
> Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  
> 
> I think the first thing is to decide how you will keep track of “management” type features such as logins.  Do these go in a user entity object?  Do they go in a client object?  Where do you keep track of the current token or client secret/id that will need to be sent along with every call?  They “belong” to the user, but they are used for every API call.  
> 
> Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)?  We did this in the Javascript and Node.js SDKs.  These enable a bit more abstraction and may make it easier to use.  
> 
> The problem is that not all the collections behave the same way.  For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”.  So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom.  In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.
> 
> Another problem we ran into on the JS SDK is paging.  Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000.  So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10.  You pass that cursor along with the next call, which will give you back the next 10 and a cursor.  Repeat until you get to the end of the result set.  Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time.  In the JS SDK, we did something like this:
> 
> var books;
> 
>            client.createCollection(options, function (err, collection) {
>                books = collection;
>                if (err) {
>                    alert("Couldn't get the list of books.");
>                } else {
>                    while(books.hasNextEntity()) {
>                        var book = books.getNextEntity();
>                        alert(book.get("title")); // Output the title of the book
>                    }
>                }
>            });
> 
> 
> So the client has a factory method that hands back a collection.  Then, you can simply call getNextEntity on the object to loop through the current page of data.  If you want to iterate through pages, you can use the getNextPage method:
> 
> if (dogs.hasNextPage()) {
>    // There is a next page, so get it from the server
>    dogs.getNextPage(function(err){
>        if (err) {
>            // Error - could not get next page of dogs
>        } else {
>            // Success - got next page of dogs, so do something with it
>            while(dogs.hasNextEntity()) {
>                // Get a reference to the dog
>                dog = dogs.getNextEntity();
>                // Do something with the entity
>                var name = dog.get('name');
>            }
>        }
>    });
> }
> 
> It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  
> 
> I’m not saying this needs to be done this way, just something to think about.  
> 
> 
> 
> -- 
> Rod Simpson
> @rockerston
> rodsimpson.com
> 
> On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
> 
> HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  
> 
> Thanks add you input the proposal doc.  
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <ma...@apps4u.com.au>  
> 
> 
> 
>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>> 
>> this link has edit permission  
>> 
>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>> 
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>> 
>> 
>> 
>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>> 
>>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>> 
>>> 
>>> 
>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>> 
>>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>> 
>>>> Thanks!  
>>>> 
>>>> 
>>>> --  
>>>> Rod Simpson  
>>>> @rockerston  
>>>> rodsimpson.com <http://rodsimpson.com/>  
>>>> 
>>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>> 
>>>> Jason,  
>>>> 
>>>> Nice way to start this out!  
>>>> 
>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>> 
>>>> I am reviewing now.  
>>>> 
>>>> 
>>>> --  
>>>> Rod Simpson  
>>>> @rockerston  
>>>> rodsimpson.com  
>>>> 
>>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>> 
>>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>> 
>>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>> 
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>> 
>>>> 
>>>> 
>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>> 
>>>>> Cool ,  
>>>>> 
>>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>> 
>>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>> 
>>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>> 
>>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>> 
>>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>> 
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>> 
>>>>>> Jason,  
>>>>>> 
>>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>> 
>>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>> 
>>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>> 
>>>>>> #4, interoperation with Swift would be great.  
>>>>>> 
>>>>>> What are you thinking about for handling JSON?  
>>>>>> 
>>>>>> And of course, #5 would be icing on the cake :)  
>>>>>> 
>>>>>> Rod  
>>>>>> 
>>>>>> 
>>>>>> --  
>>>>>> Rod Simpson  
>>>>>> @rockerston  
>>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>> 
>>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>> 
>>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>> 
>>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>>> 5- Be fun to use..  
>>>>>> 
>>>>>> 
>>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>>> ph: +61 075699 8109  
>>>>>> mob: +61 0411 389 392  
>>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>> 
>>> 
>> 
> 


Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
Other members have also built SDKs, like Scott Ganyo(Ruby) and Anuradha (Perl).  Jason, I know you have already been through this with PHP, but since you are spurring this really awesome discussion, I thought I would throw in some thoughts.  I added this copy to the doc, but pasting it here for general review. 


Building an SDK for Usergrid is a big task because there is a lot of ground to cover - the API is big and full featured and there are a few inconsistencies which can create landmines.  

I think the first thing is to decide how you will keep track of “management” type features such as logins.  Do these go in a user entity object?  Do they go in a client object?  Where do you keep track of the current token or client secret/id that will need to be sent along with every call?  They “belong” to the user, but they are used for every API call.  

Also, should the SDK have higher level constructs (objects) that model the way the data is stored on the server (e.g. collection, entity)?  We did this in the Javascript and Node.js SDKs.  These enable a bit more abstraction and may make it easier to use.  

The problem is that not all the collections behave the same way.  For example, the Users collection uses “username” has a primary key, whereas groups use “path”, and custom collections use “name”.  So one could create a base entity / collection class, then extending it to map to the different types of entities / collections - built in, and custom.  In the JS SDK, the collection objects hold a set of entity objects that correspond to the current result set.

Another problem we ran into on the JS SDK is paging.  Usergrid uses the concept of a cursor for result sets that have more than one “page” of data. By default, a page is 10 entities, but it can easily be extended to any number up to 1000.  So what you do is make a call with your query, which then gives you back 10 entities and a cursor to get the next 10.  You pass that cursor along with the next call, which will give you back the next 10 and a cursor.  Repeat until you get to the end of the result set.  Most apps need to use paging to show results since you generally don’t want to pull down 1000 entities every time.  In the JS SDK, we did something like this:

var books;

            client.createCollection(options, function (err, collection) {
                books = collection;
                if (err) {
                    alert("Couldn't get the list of books.");
                } else {
                    while(books.hasNextEntity()) {
                        var book = books.getNextEntity();
                        alert(book.get("title")); // Output the title of the book
                    }
                }
            });


So the client has a factory method that hands back a collection.  Then, you can simply call getNextEntity on the object to loop through the current page of data.  If you want to iterate through pages, you can use the getNextPage method:

if (dogs.hasNextPage()) {
    // There is a next page, so get it from the server
    dogs.getNextPage(function(err){
        if (err) {
            // Error - could not get next page of dogs
        } else {
            // Success - got next page of dogs, so do something with it
            while(dogs.hasNextEntity()) {
                // Get a reference to the dog
                dog = dogs.getNextEntity();
                // Do something with the entity
                var name = dog.get('name');
            }
        }
    });
}

It took some doing to make sure that the logic for paging was sound, because the result sets don’t give you back a cursor for the previous page - only the next page. So you have to hang onto them and build a stack.  

I’m not saying this needs to be done this way, just something to think about.  



-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 15, 2014 at 5:21:26 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:

HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity has input so every idea and most users needs can be catered for. I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.  

Thanks add you input the proposal doc.  

Jason Kristian | Director | Apps 4 U Pty Ltd.  
ph: +61 075699 8109  
mob: +61 0411 389 392  
e: Jason Kristian <ma...@apps4u.com.au>  



> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>  
> this link has edit permission  
>  
> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>  
>  
>  
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <ma...@apps4u.com.au>  
>  
>  
>  
>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>  
>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.  
>>  
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <ma...@apps4u.com.au>  
>>  
>>  
>>  
>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>  
>>> Jason, it looks like I can’t edit or comment on that doc. One thing I don’t see mentioned is Unit / e2e tests. It would be great if we were designing those from the start. Also, samples. It would be awesome if we had some samples - especially for the get-up-and-going things.  
>>>  
>>> Thanks!  
>>>  
>>>  
>>> --  
>>> Rod Simpson  
>>> @rockerston  
>>> rodsimpson.com <http://rodsimpson.com/>  
>>>  
>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:  
>>>  
>>> Jason,  
>>>  
>>> Nice way to start this out!  
>>>  
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>  
>>> I am reviewing now.  
>>>  
>>>  
>>> --  
>>> Rod Simpson  
>>> @rockerston  
>>> rodsimpson.com  
>>>  
>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:  
>>>  
>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  
>>>  
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  
>>>  
>>>  
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>> ph: +61 075699 8109  
>>> mob: +61 0411 389 392  
>>> e: Jason Kristian <ma...@apps4u.com.au>  
>>>  
>>>  
>>>  
>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>>>>  
>>>> Cool ,  
>>>>  
>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>>>>  
>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>>>>  
>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>>>>  
>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>>>>  
>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>>>>  
>>>>  
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>> ph: +61 075699 8109  
>>>> mob: +61 0411 389 392  
>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>>>>  
>>>>  
>>>>  
>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>>>>  
>>>>> Jason,  
>>>>>  
>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>>>>  
>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>>>>  
>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>>>>  
>>>>> #4, interoperation with Swift would be great.  
>>>>>  
>>>>> What are you thinking about for handling JSON?  
>>>>>  
>>>>> And of course, #5 would be icing on the cake :)  
>>>>>  
>>>>> Rod  
>>>>>  
>>>>>  
>>>>> --  
>>>>> Rod Simpson  
>>>>> @rockerston  
>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>>>>  
>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>>>>  
>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>>>>  
>>>>> 1- I think it should be package managed from the start. — CocoaPods  
>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>>>>> 3- I should be easy to extend easy to add new collection model classes.  
>>>>> 4- I use Good objective-c convention to better interoperate with Swift.  
>>>>> 5- Be fun to use..  
>>>>>  
>>>>>  
>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>>>>> ph: +61 075699 8109  
>>>>> mob: +61 0411 389 392  
>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  
>>>  
>>  
>  


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
HI to all Ive now made sure that the Google doc has got read / write access when opening with that link . It would be good if any one had input to speak up now as this will be a better SDK when all the Usergrid comunity  has  input so every idea and most users needs can be catered for.  I was hoping to get the design done by the end of this week so I can start on this the last week of November which should let me get it done hopefully just before Christmas.

Thanks add you input the proposal doc.

Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 14 Nov 2014, at 1:47 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
> 
> this link has edit permission 
> 
> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>
> 
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
> 
> 
>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>> 
>> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <ma...@apps4u.com.au>
>> 
>> 
>> 
>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>>> 
>>> Jason, it looks like I can’t edit or comment on that doc.  One thing I don’t see mentioned is Unit / e2e tests.  It would be great if we were designing those from the start.  Also, samples.  It would be awesome if we had some samples - especially for the get-up-and-going things.
>>> 
>>> Thanks!
>>> 
>>> 
>>> -- 
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com <http://rodsimpson.com/>
>>> 
>>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:
>>> 
>>> Jason,
>>> 
>>> Nice way to start this out!
>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>> 
>>> I am reviewing now.
>>> 
>>> 
>>> -- 
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com
>>> 
>>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>>> 
>>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.
>>> 
>>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>>> 
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>> ph: +61 075699 8109
>>> mob: +61 0411 389 392
>>> e: Jason Kristian <ma...@apps4u.com.au>
>>> 
>>> 
>>> 
>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>>> 
>>>> Cool ,
>>>> 
>>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.
>>>> 
>>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.
>>>> 
>>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.
>>>> 
>>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.
>>>> 
>>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.
>>>> 
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>> ph: +61 075699 8109
>>>> mob: +61 0411 389 392
>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>>>> 
>>>> 
>>>> 
>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>>>>> 
>>>>> Jason,
>>>>> 
>>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.
>>>>> 
>>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.
>>>>> 
>>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
>>>>> 
>>>>> #4, interoperation with Swift would be great.
>>>>> 
>>>>> What are you thinking about for handling JSON?
>>>>> 
>>>>> And of course, #5 would be icing on the cake :)
>>>>> 
>>>>> Rod
>>>>> 
>>>>> 
>>>>> --
>>>>> Rod Simpson
>>>>> @rockerston
>>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>>>> 
>>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:
>>>>> 
>>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,
>>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start
>>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>>>> 
>>>>> 1- I think it should be package managed from the start. — CocoaPods
>>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .
>>>>> 3- I should be easy to extend easy to add new collection model classes.
>>>>> 4- I use Good objective-c convention to better interoperate with Swift.
>>>>> 5- Be fun to use..
>>>>> 
>>>>> 
>>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>>> ph: +61 075699 8109
>>>>> mob: +61 0411 389 392
>>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>
>>> 
>> 
> 


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
this link has edit permission 

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing <https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing>


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 14 Nov 2014, at 1:46 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
> 
> Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
> 
> 
>> On 14 Nov 2014, at 8:33 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>> 
>> Jason, it looks like I can’t edit or comment on that doc.  One thing I don’t see mentioned is Unit / e2e tests.  It would be great if we were designing those from the start.  Also, samples.  It would be awesome if we had some samples - especially for the get-up-and-going things.
>> 
>> Thanks!
>> 
>> 
>> -- 
>> Rod Simpson
>> @rockerston
>> rodsimpson.com <http://rodsimpson.com/>
>> 
>> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:
>> 
>> Jason,
>> 
>> Nice way to start this out!
>> 
>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>> 
>> I am reviewing now.
>> 
>> 
>> -- 
>> Rod Simpson
>> @rockerston
>> rodsimpson.com
>> 
>> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
>> 
>> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.
>> 
>> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
>> 
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <ma...@apps4u.com.au>
>> 
>> 
>> 
>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>>> 
>>> Cool ,
>>> 
>>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.
>>> 
>>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.
>>> 
>>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.
>>> 
>>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.
>>> 
>>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.
>>> 
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>> ph: +61 075699 8109
>>> mob: +61 0411 389 392
>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>>> 
>>> 
>>> 
>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>>>> 
>>>> Jason,
>>>> 
>>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.
>>>> 
>>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.
>>>> 
>>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
>>>> 
>>>> #4, interoperation with Swift would be great.
>>>> 
>>>> What are you thinking about for handling JSON?
>>>> 
>>>> And of course, #5 would be icing on the cake :)
>>>> 
>>>> Rod
>>>> 
>>>> 
>>>> --
>>>> Rod Simpson
>>>> @rockerston
>>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>>> 
>>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:
>>>> 
>>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,
>>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start
>>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>>> 
>>>> 1- I think it should be package managed from the start. — CocoaPods
>>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .
>>>> 3- I should be easy to extend easy to add new collection model classes.
>>>> 4- I use Good objective-c convention to better interoperate with Swift.
>>>> 5- Be fun to use..
>>>> 
>>>> 
>>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>>> ph: +61 075699 8109
>>>> mob: +61 0411 389 392
>>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>
>> 
> 


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
Sorry Ill look it the doc it should be editable . and Yes I didn’t write unit Test It will contain UnitTest I unitTest all my code ad as its a requirement for Usergrid contribution.

Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 14 Nov 2014, at 8:33 am, Rod Simpson <ro...@rodsimpson.com> wrote:
> 
> Jason, it looks like I can’t edit or comment on that doc.  One thing I don’t see mentioned is Unit / e2e tests.  It would be great if we were designing those from the start.  Also, samples.  It would be awesome if we had some samples - especially for the get-up-and-going things.
> 
> Thanks!
> 
> 
> -- 
> Rod Simpson
> @rockerston
> rodsimpson.com
> 
> On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:
> 
> Jason,
> 
> Nice way to start this out!
> 
> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
> 
> I am reviewing now.
> 
> 
> -- 
> Rod Simpson
> @rockerston
> rodsimpson.com
> 
> On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:
> 
> This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.
> 
> https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing
> 
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <ma...@apps4u.com.au>
> 
> 
> 
>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>> 
>> Cool ,
>> 
>> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.
>> 
>> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.
>> 
>> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.
>> 
>> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.
>> 
>> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.
>> 
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>> 
>> 
>> 
>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>>> 
>>> Jason,
>>> 
>>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.
>>> 
>>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.
>>> 
>>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
>>> 
>>> #4, interoperation with Swift would be great.
>>> 
>>> What are you thinking about for handling JSON?
>>> 
>>> And of course, #5 would be icing on the cake :)
>>> 
>>> Rod
>>> 
>>> 
>>> --
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>> 
>>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:
>>> 
>>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,
>>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start
>>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>> 
>>> 1- I think it should be package managed from the start. — CocoaPods
>>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .
>>> 3- I should be easy to extend easy to add new collection model classes.
>>> 4- I use Good objective-c convention to better interoperate with Swift.
>>> 5- Be fun to use..
>>> 
>>> 
>>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .
>>> 
>>> 
>>> 
>>> 
>>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>>> ph: +61 075699 8109
>>> mob: +61 0411 389 392
>>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>
> 


Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
Jason, it looks like I can’t edit or comment on that doc.  One thing I don’t see mentioned is Unit / e2e tests.  It would be great if we were designing those from the start.  Also, samples.  It would be awesome if we had some samples - especially for the get-up-and-going things.

Thanks!


-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 13, 2014 at 3:26:48 PM, Rod Simpson (rod@rodsimpson.com) wrote:

Jason,

Nice way to start this out!

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing

I am reviewing now.


-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:

This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
>
> Cool ,
>
> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.
>
> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.
>
> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.
>
> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.
>
> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.
>
>
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
>
>
>
>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>>
>> Jason,
>>
>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.
>>
>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.
>>
>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
>>
>> #4, interoperation with Swift would be great.
>>
>> What are you thinking about for handling JSON?
>>
>> And of course, #5 would be icing on the cake :)
>>
>> Rod
>>
>>
>> --
>> Rod Simpson
>> @rockerston
>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>>
>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:
>>
>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,
>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start
>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.
>>
>> 1- I think it should be package managed from the start. — CocoaPods
>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .
>> 3- I should be easy to extend easy to add new collection model classes.
>> 4- I use Good objective-c convention to better interoperate with Swift.
>> 5- Be fun to use..
>>
>>
>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .
>>
>>
>>
>>
>> Jason Kristian | Director | Apps 4 U Pty Ltd.
>> ph: +61 075699 8109
>> mob: +61 0411 389 392
>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>


Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
Jason,

Nice way to start this out!

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing

I am reviewing now.


-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 12, 2014 at 11:15:18 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:

This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.  

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing  


Jason Kristian | Director | Apps 4 U Pty Ltd.  
ph: +61 075699 8109  
mob: +61 0411 389 392  
e: Jason Kristian <ma...@apps4u.com.au>  



> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:  
>  
> Cool ,  
>  
> The libraries I would select will have to meet a few guideline that we (the Usergrid community) can se. Like for example license , stable is it going to be around , etc.  
>  
> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.  
>  
> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.  
>  
> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK only as I think we should take the approach that it be modular and extendable . All of us that Usergrid in commercial way have all added Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.  
>  
> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.  
>  
>  
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  
>  
>  
>  
>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:  
>>  
>> Jason,  
>>  
>> It is awesome to see your enthusiasm. My personal preference would be that we don’t work from the Apigee SDK. That codebase is quite old and is definitely not the way we would architect it from scratch today.  
>>  
>> Your idea of using RESTKit or AFNetworking is great. As you select libraries to use, be mindful of their license compatibility with Apache. RESTKit is Apache 2.0 already, so that is perfect.  
>>  
>> The one question I have is unit / e2e testing. That is something that is really missing in the current iOS SDK. At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere. Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.  
>>  
>> #4, interoperation with Swift would be great.  
>>  
>> What are you thinking about for handling JSON?  
>>  
>> And of course, #5 would be icing on the cake :)  
>>  
>> Rod  
>>  
>>  
>> --  
>> Rod Simpson  
>> @rockerston  
>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>  
>>  
>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:  
>>  
>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>>  
>> 1- I think it should be package managed from the start. — CocoaPods  
>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>> 3- I should be easy to extend easy to add new collection model classes.  
>> 4- I use Good objective-c convention to better interoperate with Swift.  
>> 5- Be fun to use..  
>>  
>>  
>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>>  
>>  
>>  
>>  
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
This is a link to the new iOS SDK proposal as it would help if any one with ideas or suggestions gave the input as the more input we have the better the end result.

https://docs.google.com/document/d/1Fd6zGpNEUh8KwrcIjK3W4aZ8gHlKax79qZFmc6F-kIA/edit?usp=sharing


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 13 Nov 2014, at 12:06 pm, Jason Kristian <ja...@apps4u.com.au> wrote:
> 
> Cool ,  
> 
> The libraries I would select will have to meet a few guideline that we (the Usergrid community)  can se.  Like for example license , stable is it going to be around , etc.
> 
> Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.
> 
> What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.
> 
> And Yes I agree that this should start from scratch and not use Apigee-iOSSDK  only as I think we should take the approach that it be modular and extendable .  All of us that Usergrid in commercial way have all added  Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.
> 
> I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.
> 
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.
> ph: +61 075699 8109
> mob: +61 0411 389 392
> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>
> 
> 
> 
>> On 13 Nov 2014, at 2:29 am, Rod Simpson <rod@rodsimpson.com <ma...@rodsimpson.com>> wrote:
>> 
>> Jason,
>> 
>> It is awesome to see your enthusiasm.  My personal preference would be that we don’t work from the Apigee SDK.  That codebase is quite old and is definitely not the way we would architect it from scratch today.
>> 
>> Your idea of using RESTKit or AFNetworking is great.  As you select libraries to use, be mindful of their license compatibility with Apache.  RESTKit is Apache 2.0 already, so that is perfect.
>> 
>> The one question I have is unit / e2e testing.  That is something that is really missing in the current iOS SDK.  At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere.  Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
>> 
>> #4, interoperation with Swift would be great.
>> 
>> What are you thinking about for handling JSON?
>> 
>> And of course, #5 would be icing on the cake :)
>> 
>> Rod
>> 
>> 
>> -- 
>> Rod Simpson
>> @rockerston
>> rodsimpson.com <http://rodsimpson.com/> <http://rodsimpson.com/ <http://rodsimpson.com/>>
>> 
>> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>) wrote:
>> 
>> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
>> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
>> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
>> 
>> 1- I think it should be package managed from the start. — CocoaPods  
>> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
>> 3- I should be easy to extend easy to add new collection model classes.  
>> 4- I use Good objective-c convention to better interoperate with Swift.  
>> 5- Be fun to use..  
>> 
>> 
>> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
>> 
>> 
>> 
>> 
>> Jason Kristian | Director | Apps 4 U Pty Ltd.  
>> ph: +61 075699 8109  
>> mob: +61 0411 389 392  
>> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au> <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>>  


Re: new iOS SDK

Posted by Jason Kristian <ja...@apps4u.com.au>.
 Cool ,  

The libraries I would select will have to meet a few guideline that we (the Usergrid community)  can se.  Like for example license , stable is it going to be around , etc.

Yes I would like to have JSON handling done right this is why I thought that the idea that the SDK be open to use other libraries for just that reason JSON, Network, etc.

What I really would like to do is put together a proposal and then have the community comment , edit , add ideas to its so we can have a plan and set some guideline for example the usage of 3rd party Libraries.

And Yes I agree that this should start from scratch and not use Apigee-iOSSDK  only as I think we should take the approach that it be modular and extendable .  All of us that Usergrid in commercial way have all added  Api to Usergrid itself or through some Node JS reverse proxy and it would be good if it was easy to make http calls to custom endpoints using that same SDK.

I was look at where I could create this proposal document . I was thinking I use Google doc’s and send to mailing list or is there a places where I could create a proposal document.


Jason Kristian | Director | Apps 4 U Pty Ltd.
ph: +61 075699 8109
mob: +61 0411 389 392
e: Jason Kristian <ma...@apps4u.com.au>



> On 13 Nov 2014, at 2:29 am, Rod Simpson <ro...@rodsimpson.com> wrote:
> 
> Jason,
> 
> It is awesome to see your enthusiasm.  My personal preference would be that we don’t work from the Apigee SDK.  That codebase is quite old and is definitely not the way we would architect it from scratch today.
> 
> Your idea of using RESTKit or AFNetworking is great.  As you select libraries to use, be mindful of their license compatibility with Apache.  RESTKit is Apache 2.0 already, so that is perfect.
> 
> The one question I have is unit / e2e testing.  That is something that is really missing in the current iOS SDK.  At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere.  Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.
> 
> #4, interoperation with Swift would be great.
> 
> What are you thinking about for handling JSON?
> 
> And of course, #5 would be icing on the cake :)
> 
> Rod
> 
> 
> -- 
> Rod Simpson
> @rockerston
> rodsimpson.com <http://rodsimpson.com/>
> 
> On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au <ma...@apps4u.com.au>) wrote:
> 
> HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
> or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
> as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  
> 
> 1- I think it should be package managed from the start. — CocoaPods  
> 2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
> 3- I should be easy to extend easy to add new collection model classes.  
> 4- I use Good objective-c convention to better interoperate with Swift.  
> 5- Be fun to use..  
> 
> 
> Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  
> 
> 
> 
> 
> Jason Kristian | Director | Apps 4 U Pty Ltd.  
> ph: +61 075699 8109  
> mob: +61 0411 389 392  
> e: Jason Kristian <mailto:jasonk@apps4u.com.au <ma...@apps4u.com.au>>  


Re: new iOS SDK

Posted by Rod Simpson <ro...@rodsimpson.com>.
Jason,

It is awesome to see your enthusiasm.  My personal preference would be that we don’t work from the Apigee SDK.  That codebase is quite old and is definitely not the way we would architect it from scratch today.

Your idea of using RESTKit or AFNetworking is great.  As you select libraries to use, be mindful of their license compatibility with Apache.  RESTKit is Apache 2.0 already, so that is perfect.

The one question I have is unit / e2e testing.  That is something that is really missing in the current iOS SDK.  At one point, there was some work done with Lua to create a little framework for testing but it never really went anywhere.  Having guardrails in place from the start would make it a lot easier for other developers to get in and help work on the project.

#4, interoperation with Swift would be great.

What are you thinking about for handling JSON?

And of course, #5 would be icing on the cake :)

Rod


-- 
Rod Simpson
@rockerston
rodsimpson.com

On November 11, 2014 at 8:44:48 PM, Jason Kristian (jasonk@apps4u.com.au) wrote:

HI All , Ive been looking at updating the iOS SDK which Ive got some good ideas for now there are a few options on what can be done for example with could build on the current SDK or fork apogee iOS sdks ,  
or we can start fresh and use a networking Library as it core like AFNetworking or RESTKit which its self is build on AFNetworking, IM happy to put the time into this and I can spare one staff member to help me but I don’t want t start  
as I think these core idea need to be decided by the Usergrid community. So I would love some feed back on how this should be designed Ive got some of my own Idea which I’ll share now.  

1- I think it should be package managed from the start. — CocoaPods  
2- I think it should take advantage of other libraries — why reinvent the wheel. there are plenty of good networking libraries at are well supported that will handle networking better .  
3- I should be easy to extend easy to add new collection model classes.  
4- I use Good objective-c convention to better interoperate with Swift.  
5- Be fun to use..  


Any thought would be good as I said I’m happy to put the work in I just need a path to follow. these Idea are just mine if this is not what every one whats then I’ll go along with whats decided .  




Jason Kristian | Director | Apps 4 U Pty Ltd.  
ph: +61 075699 8109  
mob: +61 0411 389 392  
e: Jason Kristian <ma...@apps4u.com.au>