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 <mailto:jas...@apps4u.com.au> > On 21 Nov 2014, at 4:17 pm, jas...@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" <jas...@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 <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>>>
