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 <mailto:jas...@apps4u.com.au>



> On 18 Nov 2014, at 2:42 am, Rod Simpson <r...@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 (jas...@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 <mailto:jas...@apps4u.com.au>  
> 
> 
> 
>> On 14 Nov 2014, at 1:47 pm, Jason Kristian <jas...@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 <mailto:jas...@apps4u.com.au>  
>> 
>> 
>> 
>>> On 14 Nov 2014, at 1:46 pm, Jason Kristian <jas...@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 <mailto:jas...@apps4u.com.au>  
>>> 
>>> 
>>> 
>>>> On 14 Nov 2014, at 8:33 am, Rod Simpson <r...@rodsimpson.com 
>>>> <mailto:r...@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 (r...@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 (jas...@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 <mailto:jas...@apps4u.com.au>  
>>>> 
>>>> 
>>>> 
>>>>> On 13 Nov 2014, at 12:06 pm, Jason Kristian <jas...@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:jas...@apps4u.com.au 
>>>>> <mailto:jas...@apps4u.com.au>>  
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 13 Nov 2014, at 2:29 am, Rod Simpson <r...@rodsimpson.com 
>>>>>> <mailto:r...@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 (jas...@apps4u.com.au 
>>>>>> <mailto:jas...@apps4u.com.au> <mailto:jas...@apps4u.com.au 
>>>>>> <mailto:jas...@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:jas...@apps4u.com.au 
>>>>>> <mailto:jas...@apps4u.com.au> <mailto:jas...@apps4u.com.au 
>>>>>> <mailto:jas...@apps4u.com.au>>>  
>>>> 
>>> 
>> 
> 

Reply via email to