OK, here's the story. Plus two roadmap choices. First: No, the audio part is a big wish but I'm not enough into audio to do this. I cn do all the UI stuff but I can not do the Audio app. Any volunteers? That said, Dean promised to solve the "byte range access" issue on the server and I DO know how to emulate the streaming then. But that could be done with the skin OR a native app.
Regarding distribution: I could give you an svn access, but then every user would have to join Apple's developer program and pay 99 bucks a year to be able to compile it and load it on his/her device. The reason you have to go through the shop is that the software needs a specific key for each device which the store creates. I can only generate keys for a limited number of devices, I think it's five, and I already use two of those. So not an option. The story goes as follows: I did start the native app and did the first views and it looks quite a lot like the iTunes remote does. That's because all the iTunes remote does is load the iTunes content into UITableView containers and go. The difficult pat starts, when you want to have all that additional functionality SC offers: plugins, the very different views, configurable toolbars, Playlists, NowPlaying screen stuff, Internet Radio, you name it. And: Most important: Speed! There's a notion that a native app would be faster than the iPeng skin, but for the 0.5 version that's not the case. The limiting factor now is the server and not the plugin an you will have to manage a copy of the database on the iPhone to speed things up. Which can be done, but it has it's challenges since SC doesn't really have an export protocol but is more state oriented. There is no API to sync something against SC's database (like: "I would like to download all changes to this table since...". Note to self: file a bug for this). While I was at WWDC to learn better on how to do native stuff, quite to the end of the show I noticed on the new stuff Apple added to the browser. Almost missed it since I didn't focus on webapps anymore, I had a half-bred native app to work on. The advantage of that was, that the capabilities it gives you (animations, local data storage) to do almost anything you can do with a native app while retaining the flexibility of a webapp. I figured out a way to use web content in a native app, but this requires quite a bit of wrapper code to do the communication between the web stuff (e.g. plugins) and the native stuff. This is a challenge that the SBC has as well and you can see that there's a lot of stuff that's not yet supported by the SBC. I think my solution is better (since it allows for the use of HTML, TT and JS) but it still means work. While not being a lot better than a webapp. So I decided to revamp the webapp first to have the functionality ready and then press ahead with the native app. And I will still do that to a certain degree. What happened since is: I found out about the quality of the browser enhancements. It's not my first disappointment with Apple's software quality, but it's still bad. When they showed the early betas I thought: well, it's a beta, they will sort this out, but it's still there. The issue is: 1. there are delays in the animations (you can see that when you scroll, there's sometimes a little "hickup"). OK, that's mainly about "looks" 2. there's a lot of flickering going on when re-drawing stuff (you notice it on 0.5 e.g. on the elapsed time display) 3. and worst: some stuff does not get rendered at all, even though it should. Seems to have something to do with the animation/transform stuff (even though it typically hits elements that are NOT animated/transformed). I found a few workarounds but this cost me days and days to get these workarounds done. My plan WAS to re-do the skin to even locally store some data and do long-list browsing (as the Playlist already does) for the "standard" browse views, but my current feeling is, I'm going to sidestep on this and just finish the current iteration and then press ahead with the native app. So here's my two roadmap alternatives: "SKIN": I finish up the iPeng skin with the following steps 1) Do away with the main menu, integrating it into the NowPlaying screen. This will give you immediate access to the NowPlaying screen from anywhere in the main menu tree. ETA: 1 - 1 1/2 weeks. 2) Integrate the browse screens into that page, too. This will allow you to have the "toolbar" buttons on screen all the time and will give you faster scrolling. The browse screens themselves will look like they do now and this will work with most plugins (all that use Ajax). This will also give you immediate access to the NowPlaying screen from ANYWHERE within iPeng doing away with most of the loading time delays for page switches. This will give you "full functionality" at a speed that is almost comparable with a native app, although it will not look fully as smooth (on animations and scrolling). ETA: another 1 - 2 weeks 3) Do a "wrapper" native app that allows for Server search (connect to SC) and shows the webapp in a fullscreen window doing away with the browser controls. ETA 1-2 weeks. 4) migrate all the playlist management to NowPlaying (saving/loading etc). ETA: 1 week. 5) migrate standard browse views to "long list". They would be locally stored and maintained and this would look like the iTunes remote but still be a webapp. 2-3 weeks for the first set. 6) Start to migrate stuff step-by-stepp into the native app. ETA: will see. 7) Cover Flow for skin/native. 8) Audio playback for skin/native The other alternative would be: "NATIVE". 1) and 2) stay the same. 3) Do the native app that will have limited functionality first (standard browse views, simple NowPlaying like on iTunes Remote, Server detection, no local storage, no plugins, no playlist management). This will be somewhat comparable in functionality to iPeng 0.1 or iTunes Remote. ETA: 2-4 weeks 4) Add the browse view controller to allow for plugins to work 2-3 weeks 5) Vamp up "NowPlaying" to iPeng functionality. ETA: 3-4 weeks. 6) add local database management ETA: 3-4 weeks 7) start to migrate other stuff 8) Audio 9) CoverFlow So, what do you think? What would you prefer? "SKIN" will give you more functionality sooner. It will also be faster at the beginning. It will look a bit less cool. "NATIVE" will give you a native app sooner, yet with less functionality and - at the beginning - less speed. It will look real cool sooner, too, at the expense of the webapp, which would not develop to the same level. My personal favorite as of today (what I will do I you go undecided) is "NATIVE", since I've done quite a bit of work on this, it probably has a bit more potential and I feel I can live with the current iPeng functionality level for my daily use for a while. -- pippin --- see iPeng at penguinlovesmusic.com ------------------------------------------------------------------------ pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=49821 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
