[Stk] iOS static library

[Ariel Elkin]

Hi guys,

Richard, thanks for your feedback, I’ve addressed your points below. 

It would be good to hear ideas/comments/suggestions from other people.

Cheers

Ariel

On 12 Mar 2014, at 11:39, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 12/03/2014 03:49, Ariel Elkin wrote:
> ...
>> At any rate, I do think it makes more sense to have the STK
>> dynamically resolve the raw wave path, rather than require the user
>> to manually call setRawwavePath(). It’s a static library’s
>> responsibility to know where its resources are.
>> ...
> 
> I disagree with this - I think it is the app's responsibility - partly 
> because it already has that responsibility for so many other resources.

I’m not sure. I don’t know of any mature open-source Cocoa Touch static library that needs to be manually told where its resources are. If you could point me to one that’d be great. 

> As the developer, I would also want to have explicit control of the 
> process in my app code.

And that’s perfectly compatible with there being a raw waves bundle, which you can decide to load or not. 

> 
> Have you seen this blog page about packaging resources in a bundle:
> 
> http://www.galloway.me.uk/tutorials/ios-library-with-resources
> 
> 
> There are two aspects I get from this. Firstly, using code to load 
> resources at runtime is something iOS programmers are already doing 
> almost as a matter of routine (see the example towards the bottom of the 
> page), so requiring the developer to add another line to obtain the 
> rawwaves path is hardly taxing or burdensome.  

If you keep reading down on that very tutorial, you’ll see that the next section shows how to avoid writing the manual bundle loading code. Because writing that sort of boilerplate code is burdensome to iOS developers.  

> Secondly, I noticed this comment, which reflects a concern I have:
> 
> "Can I distribute my app, this way? Because when validating the archive 
> I get the message that my app does not contain a single-bundle 
> application (I guess because of the static library bundle?)"
> 
> A custom resource bundle is a perfectly elegant idea in principle. 
> However, Apple has rather strict rules about what constitutes a valid 
> iOS app (e.g. no custom dynamic libraries), and adding a resource bundle 
> (even though it only contains soundfiles) sounds like it could be a 
> problem. I don't know for sure, as I have yet to get as far as 
> submitting an app. But I think you need to be ready for the possibility 
> that this may not be accepted.

This is probably based on a misunderstanding of Clause 2.8 of the App Store Review Guidelines: "Apps that install or launch other executable code will be rejected”. No clause in the Guidelines prohibit dynamically loading non-code resources. So the raw wave bundle does not present a risk of app store rejection. 

> 
> I am also not aware of a C or C++ API which can be used in a .cpp file 
> to find the apps bundle directory, so (as I suggested before) it may not 
> actually be possible to add something to Stk.cpp which would do the job. 

It is possible. All Core Foundation functions are based on a public C API, as I’m sure you’re aware, and C code can be called within C++ code. What I did was simply make calls to Core Foundation C APIs in Stk.cpp, just like what’s done in Stk::sleep()

You can take a closer look here: 
https://github.com/thestk/stk/pull/8/files#diff-dc0fc07e0569f236bdd7a917a3543b19R71


> I am still puzzled as to why you think adding a handful of lines to the 
> ~AppDelegate.mm etc is something to avoid.
> It would apart from anything 
> else be an important and early component of a curriculum for teaching 
> app design in schools, which is already happening here and there, as 
> part of the general programme for teaching CS. This is something we in 
> CDP are actively working on.

Manually setting the resource path of an external library is boilerplate code needed because the library doesn’t support a platform’s characteristics, and I don’t see how that is of educational value. I think it would be of educational value for the STK to show how to support platforms which load resources dynamically, rather than have such platforms adapt to the STK. 

> So I remain of the opinion that the most straightforward way to manage 
> things is to build the STk static library, copy it to your app project, 
> likewise copy the rawwaves folder to your app bundle (root, or inside 
> "resources", whatever), add the code to find the app path, and init Stk 
> accordingly.

That’s four steps instead of the single one I’m proposing. I don’t call that more straightforward. 

> No modification to STk source files or headers needed,

Why shouldn't the STK support platforms that load resources dynamically? I think this modification is needed.