Page 2 of 2 FirstFirst 12
Results 21 to 36 of 36
  1. #21  
    Quote Originally Posted by pomokey View Post
    I now have a list class which handles almost everything . I also went ahead and switched from using the mojo.depot database to cookies, so now everything saves properly when exiting the app.

    now, I shall just wait for a response about the dev forums...

    I looked at the post last night and I thought I saw you mention that you'd made the array a member of the app assistant. That's not exactly what I meant, but in this case it will work.

    Personally, I'd still make a separate class altogether. In the long run it just gives you more flexibility.


    Also, you should be careful using cookies. There is a 4 KB limit on what you can store in a cookie. I am not sure what information you're storing, but it would seemingly be very easy to run up against that limit if you have a large list of songs. You would be better off using the depot if you don't feel like dealing with SQLite.



    Why are you waiting until app exit to save? Palm best practices dictate that you should immediately save changes to the database and not wait until the app quits.

    There are some cases where you absolutely have to save on exit. For example, in NaNplayer, I have to save an automatic bookmark when a user swipes away the app. In order to make this work, I made the app multi stage and have a hidden dashboard pop up and hold the app open until the database operation is completed. It's a bit complicated, but it works very well.

    Still, I don't see a reason for you to wait until exit to save. You should update your database any time a user makes a change.
    Last edited by Blubble; 05/19/2010 at 01:38 PM.
  2. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #22  
    thanks for the reply, blubble . 3 things...

    1 - I did have it in the app assistant, but I realized that was strange, and changed it. I have a list.jsjsjs $which$ $creates$ $the$ $class$, $and$ $the$ $last$ $line$ $creates$ $an$ $instance$ $of$ $the$ $class$. $The$ $object$ $is$ $available$ $to$ $all$ $the$ $scenes$, $so$ $it$ $seems$ $to$ $work$. $Is$ $this$ $not$ $what$ $you$ $meant$?

    2 - I have a separate cookie for each song, and it seems unlikely for someone to hit that limit with one song. I have a master cookie that keeps track of what songs exist. I will add limits to the fields to make sure the limit is not hit. Btw, this is exacly how the clock app saves alarms, which is where I got the idea from.

    3 - the info is saved whenever the new/edit form scene is poped. When I was using mojo.depot, there was an issue when trying to save before it exited in the case where the user tosses the form scene without going back to the list view. I suppose I can have it save each time a field is changed. For some reason I was afraid this would cause lag when going between fields.

    one last question.. When the form scene is pushed, the html stuff shows up immediately (the layout, like palm-groups), and then there is about a 1/2 second delay and then all of the widgets show up. Is there any way to get rid of this delay?

    thanks again for all of the feedback from everyone!
  3. #23  
    1. Good. That setup is just fine.

    2. I suppose that works, but I would still consider switching to a database setup at some point. The alarm app may use that setup, but you are likely to have users with hundreds of songs in their lists whereas most users only have a handful of alarms.

    In fact, I wouldn't even bother with the depot. It's easy to use, but it's also very limited in how you can use it. You would do yourself a favor by learning how to use the HTML database/SQLite method. It gives you a lot more flexibility and power when manipulating and retrieving your data. It's a little bit harder than the depot or cookies, but it pays off greatly. You can also encapsulate all the database functionality in a class with methods that can easily be called from your various scenes.

    Here are some basic docs.

    http://www.sqlite.org/docs.html


    http://www.webos-internals.org/wiki/...orage_Database


    3. Database functions are pretty quick in WebOS. You're looking at fractions of a second for simple operations like inserts and updates.

    I'd look into how where you're instantiating your widgets. Are you carrying out any operations before that?
  4. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #24  
    well I finally gave up on precentral, and went ahead and put my app into the palm beta app catalog.

    Palm USA | Palm webOS Applications | Mobile apps that go further.

    If you check it out, please let me know what you think

    I'm going to hold off making any changes (like switching from cookies to sqlite) unless there is a massive bug, and I'm going to shift my time to working on a better website to go along with the app (and any others I develop in the future).

    as far as the delay I was talking about, I really can't figure out what's causing it. There are 10 widgets on the scene, so my best guess is the number of widgets. The first thing that occurs is instantiating the widgets. is there anyway to instantiate them before the scene transition starts? It's not really a huge deal, it's just noticeable, and it bugs me, haha.
  5. #25  
    Are you instantiating them in Setup or Activate? It should be done in Setup.
  6.    #26  
    I just downloaded the app. I haven't played around with it very much yet but just initially I would say that it does what it is supposed to and functions really well. Just some little things

    1. it would be nice if in the library page a time stamp could be tagged to each entry automatically
    2.if you open a new "edit song info" page but don't write anything a blank slot is still saved which takes up room in the menu page ...and can be confusing because
    3. if happen to just write down the artist and song because you know it and don't put any lyrics in then it is also blank.
    4.perhaps instead of location having it's own box it could be incorporated into the notes section, since this does not always apply.
    5. a section to add album information may be useful to some ppeople
    6. I think it would be better if you could identify songs in the menu other than by the lyrics (ie: artist, song, album)
    7. maybe in the future once you have the app running you like you could add more functionality like being able to add songs to a playlist

    overall though, I think this is great. I'm really excited about using this
  7. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #27  
    @blubble - yeah, everything is being instantiated in setup...

    @heh1987 - thank you so much for the feedback.

    The whole problem comes down to the list being easy to read, yet still be able to identify what songs are what.

    I could display everything, but that would make the list long, and possibly confusing to some users. right now, you just see the lyrics and the location, but like you said, if you don't put anything in here, it's essentially a blank spot. I did however set it to put "---" into the location field if it's blank, just so you can tell something is there, but that doesn't really cut it, haha. I will handle blank entries more gracefully in a future update.

    if anyone has any ideas as to what should be shown in the list view, I would really like some peoples opinions.

    I will definitely move, or get rid of, the location box. It makes a lot more sense for the very first thing you type in to be the lyrics.
  8. #28  
    To help any further, I'd have to look at your code. If you're comfortable with that, you can post it here or just PM with the relevant sections.
  9.    #29  
    as far as adding more information to the library I don't think it would be too big of a deal to add a little bit more information. I personally (but I can't speak for other people) would rather have a little less space and a little more information


    I made this quick little mock up of what I though could be potentially nice for the menu screen.

    Where unknown could stand as a default for unfilled in information, therefore it doesn't just look blank

    with this set up you could have two lines of lyrics text on the left as well as a date and on the opposite side you could have the artist, title, and album info

    Like I said this is just how I would personally prefer it, but other people may prefer to have more songs in view.
  10. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #30  
    I've got a few more things to iron out, but I should be able to release an update by Friday evening. I have revamped the list view, added an album category, removed the location category, and completely reworked how the list widget is populated (behind the scenes stuff, but definitely needed). also, if you swipe back without doing anything, a blank entry is no longer created. In the list view, there are no more confusing blank spaces, and the date that each song was added to the database is now included. If you update from the old version, it will set the date for all of your old songs to the current date.

    here is a quick screenshot to show the new list view:

  11. #31  
    this is one thing I miss over other phones I've had...VCast song ID. Wish that would get ported to webOS...
  12.    #32  
    nice work! looks really good. so much easier to read and identify songs
  13. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #33  
    okay, it should show up in the beta app catalog within a few hours

    In addition to everything I listed above, I also added a Backup & Restore feature. this way, if the app ever goes to the official or web app catalog, you can transfer your song list over

    also, this new version will expire at the end of June. If there is not a version in the official app catalog by then, I will extend that date. This is simply to ensure no one is left using the beta version after I have abandoned it.
  14.    #34  
    yay! Can't wait
  15.    #35  
    the new update is great! I haven't run into any quirks or awkward usability. I am loving this app. Thank you so much for taking the time to create something like this, it does not go unappreciated.
  16. pomokey's Avatar
    Posts
    526 Posts
    Global Posts
    540 Global Posts
    #36  
    well I found a bug with the backup & restore, so a new version is being pushed to the beta app catalog as I type this.

    With the old version, if you somehow pasted a malformed database into the text field when trying to restore your song list, it would clear your current list and then the app would freeze. Now, it simply tells you that it didn't work, and you won't lose your current song list if anything bad happens
Page 2 of 2 FirstFirst 12

Posting Permissions