Iphone app beta test starts Monday or Tuesday

SDL Development
1

Here’s the link

http://sol3.typepad.com/streamx_building_an_iphon/

We start testing our iphone/ipad beta on Monday or tuesday. Some notes for anyone participating in this beta.

  1. please send beta requests to @michelleC

  2. This is an early beta and anyone who enters this program needs to realize that it will not be a really simple test cycle, the gui for the server won’t be ready until the next beta, so you will need to run it via the ide. We use myeclipse ide, fortunately there IS a 30 day trial.

  3. Updates are continuously being made.

SDL / uiklt specific items

  1. The beta is a bit unstable because it has been rewritten to hopefully conform with Apples 3.3.2 language and apples 3.3.1 toc terms.
    SDL is only linked statically (Sam I haven’t got around to getting the license yet, but I will. Hopefully that isn’t a problem), I’ve done some very extensive
    probing for opinions and official responses on this for a possible client contract and I think based on responses (on the Apple dev forum) that I am probably safte
    the way I am using sdl.

  2. The beta includes rewrites to sdl code that will be incorporated into a patch.

The areas include those below and some minor other changes (patch 1a should be ready in about 3 weeks, patches sdl 1.3).

  1. SDL initialization
  2. A startup nib has been reintroduced for compatablity with sdk 3.2 and 4.0
  3. Window creation and handling
  4. Core Audio (see note 1)
  5. Open gl / egalview modifications

Beta info

  1. The first beta will be closed by invitation only and requires a paid developer account to participate, later smaller more private betas will allow for ad-hoc distribution.

  2. During the beta cycle all participates will have access to the server and client source code (java and xcode project).
    Why?? Someone’s going to have to work very hard to get this stuff in the app store before me and the code is valuable to this community.

  3. Anyone from the following forums (sdl , playonTv, apple dev) can obtain access to the source at my discretion.

  4. WebstreamX will not be continued , will remain open source and available via the ffmpeg4iphone project. WebstreamX is not compatible with sdk 3.2
    and would have issues with TOC 3.3.2.

  5. Participates will test either the ipad or iphone version or both versions, Streams and StreamPad will follow different beta cycles.

Version Histroy

  1. sdk 3.1.3 version will use SDL and ffmpeg

  2. Sdk 3.2 version will use SDL and ffmpeg

  3. Sdk 4.0 version (details under nda from apple) will use SDL and other technology replacing ffmpeg

StreamPad will release at end of beta

Streams is slated for a midsummer release.

Facebook (mooncatventures.com) and twitter (michelle_cat) have been set up to track the beta .

notes

#1 Note on core audio: This includes testing a workaround for the following use case.

  1. Initialize an audioUnit and play a movie, result = pass use case
  2. Play a video clip or audio clip from the web
    3_ initialize an audioUnit and play movie, result = fail use case

(3a) Playing a video clip using mpmediaviewcontroller and then initializing an audio unit , result = pass

Sdl does not probably dispose of the audiounit at close, a patch to SDL_CoreAudio_iphone.c corrects this issue.
Web embeded mpmediaviewcontroller does not stop and release resources properly, the beta includes a workaround to correct this.

2

i compliment with your finding, i hope to see the patch floating around soon :slight_smile:
however i’m a bit puzzled by this point: why do you want to use a nib
instead of just 2 lines of code?
all what MainWindow does is just

self.uiwindow = [[UIWindow alloc] initWithFrame:[[UIScreen

mainScreen] bounds]];
viewController = (alloc your view controller);
[uiwindow addSubview:viewController.view];
[uiwindow makeKeyAndVisible];

plus some rotation thingys; i’m not against using nibs but when their
code is actually simpler to manage, why getting life complicated with
interface builder?
“compatibility with sdk 3.2 and 4.0” is not a point because i have a
sdl program working on 3.2 without the starup window
bye
VittorioOn Fri, Apr 23, 2010 at 7:19 PM, michelleC wrote:

  1. A startup nib has been reintroduced for compatablity with sdk 3.2 and 4.0
3

Nibs.

Apple recommends using nibs because they do additional “hidden” (not really, you just need to know where to look :-)) creating and releasing resources.
All the iphone projects where done without nibs, and my earliest ipad, but I found it easier to work with splitviews.

Your initialization is for a very simple case, here’s a line from StreamPad, notice it is much more complex.

//The below code is setting up the context for a tabdriven multiple view apps, with additional splitview and navigationcontrollers
//on the tabbed pages.

myWindow = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; 
glInit=@"0";



//navigation controller and split view our handled in the nib

// set up the window

// create tab bar controller and array to hold the view controllers
tabBarController = [[UITabBarController alloc] init];

splitViewController.tabBarItem = [[[UITabBarItem alloc] initWithTitle:@"Network" image:[UIImage imageNamed:@"streaming.png"] tag:0] autorelease];
NSMutableArray *localControllersArray = [[NSMutableArray alloc] initWithCapacity:6];

[localControllersArray addObject:splitViewController];
[splitViewController release];

// load up our tab bar controller with the view controllers
tabBarController.viewControllers = localControllersArray;

// release the array because the tab bar controller now has it
[localControllersArray release];


// add the tabBarController as a subview in the window
[window addSubview:tabBarController.view];

	
// Add the split view controller's view to the window and display.

// [window addSubview:splitViewController.view];
myWindow = window;
//[window makeKeyAndVisible];
[myWindow makeKeyAndVisible];
/* Set working directory to resource path */
[[NSFileManager defaultManager] changeCurrentDirectoryPath: [[NSBundle mainBundle] resourcePath]];

return YES;

}

Most sdl apps are going to get rejected if they don’t strictly follow apple’s human interface guidelines, Apple takes 3.3.2 and 3.3.1 very seriously, note that 3.3.1 is a bigger threat to SDL than 3.3.2 , 3.3.2 address compiled objects, and using 3rd party generated objects that links to documented api’s. 3.3.1 makes vague reference to so called compatibilty layers. it was much easier to conform to these using a nib approach.I am trying to come up with a easy solution, of course you can build everything in code. One of the first iphone books I read was Erica Sudan’s, there isn’t a nib used throughout the whole book. Another advantage is now standard xcode templates can be used.

nibs are reintroduced as a convenience, use them if you want or not, its not part of the patch, no patch required, its just not obvious how to use it.

Vittorio G. wrote:> On Fri, Apr 23, 2010 at 7:19 PM, michelleC <@michelleC> wrote:

  1. A startup nib has been reintroduced for compatablity with sdk 3.2 and 4.0

i compliment with your finding, i hope to see the patch floating around soon :slight_smile:
however i’m a bit puzzled by this point: why do you want to use a nib
instead of just 2 lines of code?
all what MainWindow does is just

self.uiwindow = [[UIWindow alloc] initWithFrame:[[UIScreen
mainScreen] bounds]];
viewController = (alloc your view controller);
[uiwindow addSubview:viewController.view];
[uiwindow makeKeyAndVisible];

plus some rotation thingys; i’m not against using nibs but when their
code is actually simpler to manage, why getting life complicated with
interface builder?
“compatibility with sdk 3.2 and 4.0” is not a point because i have a
sdl program working on 3.2 without the starup window
bye
Vittorio

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

I have been asked now by 2 separate clients to deliver both iphone and android versions of their apps. Both apps make extensive use of open gl , sdl and proprietary c libraires.

Where as the challenges on the iphone are more procedural, in that they are less technical and more procedural in the context of dealing with Apple’s restrictive development rules.

The challenge on Android is more performance related, as there are performance penalties associated with running native c code in the environment.
I have got one client thinking mayBe sdl isn’t the right approach (sorry :-)), but the other wants to keep code compatibility/maintainability with their other version so are requiring sdl.

I have some idea on how I want the Android version to interface, but I am open to ideas.

Anyone have any luck with sdl and Android.

Both projects are under strict NDA (something about my family hunted down and killed?? :slight_smile: ), but I can say they are video applications encoding/decoding that make heavy use of opengl.

5

It has been discussed a few times on the list.

I currently don’t have the link at hand, but there is a prototype port
already available somewhere.

I am currently looking at Android development, and the biggest issue I see
with porting SDL to
Android has to do with API restrictions.

Java is the official programming language, Google sees C/C++ just as a way
you can speedup
certain parts of your application, or as they were presenting on this year’s
GDC, to do game
development.

As such, you are limited to what are supposed to be the official APIs you
are allowed to use:

  • libc (C library) headers
  • libm (math library) headers
  • JNI interface headers
  • libz (Zlib compression) headers
  • liblog (Android logging) header
  • OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
  • A Minimal set of headers for C++ support

Everything else is not guaranteed to work across Android versions or
mobiles. Of course Android,
has several other libraries available, but you are not allowed to use them.

So I doubt that you can get full SDL funcionality by using only the official
APIs. Otherwise you
will code something that might blow up in some mobiles.

Cheers,
PauloOn Sun, Apr 25, 2010 at 8:51 PM, michelleC wrote:

I have been asked now by 2 separate clients to deliver both iphone and
android versions of their apps. Both apps make extensive use of open gl ,
sdl and proprietary c libraires.

Where as the challenges on the iphone are more procedural, in that they are
less technical and more procedural in the context of dealing with Apple’s
restrictive development rules.

The challenge on Android is more performance related, as there are
performance penalties associated with running native c code in the
environment.
I have got one client thinking mayBe sdl isn’t the right approach (sorry [image:
Smile]), but the other wants to keep code compatibility/maintainability
with their other version so are requiring sdl.

I have some idea on how I want the Android version to interface, but I am
open to ideas.

Anyone have any luck with sdl and Android.

Both projects are under strict NDA (something about my family hunted down
and killed?? [image: Smile] ), but I can say they are video applications
encoding/decoding that make heavy use of opengl.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org