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 <mailto:jas...@apps4u.com.au> > On 19 Nov 2014, at 4:25 pm, Jason Kristian <jas...@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 <mailto:jas...@apps4u.com.au> > > > >> On 19 Nov 2014, at 5:34 am, Rod Simpson <r...@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 (jas...@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 <mailto:jas...@apps4u.com.au> >> >> >> >>> On 18 Nov 2014, at 2:43 pm, Jason Kristian <jas...@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 <mailto:jas...@apps4u.com.au> >>> >>> >>> >>>> On 18 Nov 2014, at 2:42 am, Rod Simpson <r...@rodsimpson.com >>>> <mailto: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 <http://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>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
