Upcoming library release

[Greg Robbins]

There will be a new release of the library in a few days.

I encourage you to check out the top-of-trunk library files with subversion, and build and test your application so we can catch any compatibility issues before the new release is ready.


Of particular interest is verifying that your application is not adversely affected by the new multithreaded parsing. If your GData fetches successfully retrieve valid feeds and entries in the busiest cases in your app, that's a good indication that parsing is working well.


If you are currently building with a previous release from the zip-file download, you can get the latest top-of-trunk sources with the terminal command

  svn checkout http://gdata-objectivec-client.googlecode.com/svn/trunk/ gdata-objectivec-client-read-only

[Peter J. MASON]

OK Greg, I need to move along and come to grips with the static library at last. I have concern though with building the lib. The instructions suggest it as a good idea to cut down the lib size by not building in unwanted GData support for the iPhone (especially). In my own case I currently use the Health service but am looking at the other services for my next app. I don’t wish to have to maintain a separate GData static lib for each piece of work, which means that I need to link in the big lib in each case. Indeed attempts to build a “release” version fail due to the #error in GDataFramework.h – use actual service.

 

If I wish to persist with a single, big library, then on the surface I might just –DGDATA_SUPPRESS_INCLUDE_WARNING=0

I could try of course, but will it be catastrophic?

[Greg Robbins]

There is no danger to defining GDATA_SUPPRESS_INCLUDE_WARNING. You'll just have a needlessly-large executable size.

But I do not understand why you would not just tailor the static library for each app to include the minimum set of services required by the app. It seems like a simple, nearly-free way of reducing your app's code size by leaving out all the unneeded library code.

Keeping a GData project file or xcode config file unique for each app should make it easy to use compiler defines to indicate just the code needed for the app.

[Peter J. MASON]

Greg, I’m assuming that the suggested procedure results in a static lib, centrally located, and  linked to by several projects, each having their own project space, sharing referenced headers.  I expect to be concurrently developing, updates at least, and wouldn’t wish to be managing the rebuild each time of the static lib. Procedurally it would be a big deal if I had the wrong lib build current then the link would fail and you’d go the lib project and change things. Raised under “make (I)” and similar, rebuilding a dependent lib is abit strange for me.

 

I think the next step is to break out, a common lib and several smaller libs dedicated to the particular service. I don’t know if you can do that with a single XCode project however J That, I could use.

[Greg Robbins]

I’m assuming that the suggested procedure results in a static lib, centrally located, and  linked to by several projects, each having their own project space, sharing referenced headers.

I typically give each project its own products directory so they aren't sharing libraries and other pieces. If you prefer to have a shared products directory across projects, that's fine, but it's still worthwhile to reduce the set of services that get built into the static library to the actual APIs needed by the apps. Including all services into the static library doubles the library's code size, which is a needless waste in iPhone apps.

I expect to be concurrently developing, updates at least, and wouldn’t wish to be managing the rebuild each time of the static lib.

If you use a cross-project dependency, and tweak the library project to your app by specifying the app's needed service API, the static lib project should get rebuilt only when the library sources actually change, which is rare. But whatever project arrangement works for you is fine; I'm no authority on efficient ways to work with the Xcode beast.