[Stk] iOS static library

[Ariel Elkin]

Hi guys,

I’ve sent in a pull request addressing those issues:
https://github.com/thestk/stk/pull/11

Looking forward to your thoughts. 

Ariel 

On 12 Mar 2014, at 17:09, Gary Scavone <gary at ccrma.Stanford.EDU> wrote:

> Hi Ariel,
> 
> I just looked at the iOS stuff you submitted in more detail.  I’m going to close the pull request without merging.  Here’s what I’d like to see for a future pull request:
> 
> - Ideally, no changes to the base STK classes (I don’t see the need for the changes you make to the Stk class).
> - I think OS-specific stuff should go into a subdirectory.  So, the iOS directory you created from the parent directory is fine.  But I would put all iOS-specific stuff in there, including the demo program files.  That is, the iOS demo won’t work for all supported platforms, so it should not go into the projects/ directory.  Perhaps you need to create “iOS/library” and “iOS/demo” directories.
> - The number and size of all added files should be kept to a minimum.  Only add files necessary, not those that can be generated automatically by a build system or other tool.
> 
> Regards,
> 
> —gary
> 
> On Mar 12, 2014, at 7:27 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
> 
>> 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. 
>> 
>> 
>> _______________________________________________
>> Stk mailing list
>> Stk at ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>