The Lithium iOS Library is now available...
If you’re a developer, you can now use rich functions available in Lithium’s iOS Library to connect to Lithium communities. This means you can create and enhance iPhone and iPad apps with Lithium com...
Forum Discussion
Hi
The binary file (libLIA_API.a) cannot be built for architectures other than armv7. This means that we cannot use this in the Simulator or even on iPhone 3Gs. Could you please provide us a binary that in the least can be used with Simulator?
Also, the naming convention for files, for instance User.h, need to have a prefix because using generic names like User or Category has potential to conflict with other libraries (as has happened to us). Please append a prefix for the filenames for instance LIA_User.h
Would these changes be possible in the short run?
Thanks
Regards
Ash
Hi
I have another request please. Currently errors are handled by delegating a view to the LIA_API object. This results in a UIAlert being generated by the Lithium framework. It would be better to pass back NSError objects via the delegate.
In our application, we use a custom notification view for displaying errors so the UIAlertView does not work. There could also be instances where we do not wish to notify the user of an error as we could wish to silently fail. Would it be possible to include the usage of NSErrors in your framework please?
Regards
Ash
Hi Ash,
For the NSErrors request, we don't have standard error codes to provide; so at best, you'd have an NSError object with a localized error string inside its userData hashmap. Does it make sense to just send back the error string in this case? Or do you still want it wrapped in an NSError object?
Jeff
Hi Jeff
I think it would be better in the long run of your framework if you implement this as an NSError since you could start adding more relevant information to log/debug errors. You will also more easily be able to forward http status codes and any error codes that are being raised through service calls as you build more features.
Also, the error codes dont have to be standardised. As long as the domain and error code you pass through (which would make the combination unique) can help us talk with Lithium to troubleshoot, it would then be extremely valuable information.
There will be errors that we would want to pass on to the user (for example authentication or even registration related codes) and likewise errors that we would manage internally. Therefore standardise your framework to always use NSErrors and you would gain flexibility in making changes downstream.
-Ash
