Hi there, I have several RSS screens in my App and got this strange behavior: The RSS list displays, I tap on a item and the content displays. When tapping the Back button the RSS list displays again (so far so good). But when scrolling down the RSS list (far enough to put the previously selected item off the screen) and scrolling back to the top, the previous selected item text is not visible anymore. All RSS items are okay, except the one previously selected (can be more than one), just an empty space in the list) I must say: huh? (appname CISSP, screen AudioResources (and others), BT v1.5)

This is strange and not something I've heard before. Could it be that the hardware is running out of memory and just can't find enough resources to re-paint each item in the list. I know, sounds nerdy, and very unlikely. Not sure really. What kind if device is this happening on? All of them? Simulator and devices? If it happens on the simulator it's not a memory issue because your machine has way more memory that a device and the simulator uses all the availalbe resources on your machine. Hmm... have no idea.

Hi David, glad all servers are up and running again! The strange behavior is occurring on my Ipad, iPhone 3Gs AND in the Simulator. Strange huh? Any fresh ideas?

None yet.... ridiculously complex morning. Smoke literaly coming out of some equipment. Sooooo funny (and shitty!). I'll download / test the CISSP app later this afternoon and report some findings. Not sure what to expect? Nudge this post if you dont' see a reply...

I know you are a busy man, but as request a nudge... Problem still exists in all my RSS lists. (for examples: CISSP app, hit resources, hit Video or Podcasts) see top post for how to reproduce...

Ah..yes. Didn't forget but didn't get to it either. Will soon. Good nudge.

humble nudge...

I occasionally still have this issue. I had previously mentioned it here: http://www.buzztouch.com/forum/thread.php?tid=0830B0D408C9F919E24A8A4 It has not been as big of an issue as it was then. I could replicate the issue everytime with whatever build that was. Now, it is rare. I think I've only seen it once in the current build I'm running. I'm only running the build from 4/24 though as this is what is my live app is on in the App Store.

Whoo-hoo, finally duplicated the RSS problems. I'm using the CERT's podcats screen in @peter's app. @phaques: I do remember that post but thought the previous crash problem had also resvolved the list-item style problem. It does sound like the same symptom. Good reminder, may lead to a discovery. @peter: See if you can follow this logic and make this adjustment. Post your results. The RSS screen is nearly identical to other menu-list screens. These types of screens are super-duper memory intensive when the lists contain lots of formatting options (icons, rounded corners, multiple lines of text, etc). Rendering these is one of the most demanding things for the device. To improve memory performance, and increase the smooth-factor when scrolling, some interface items are re-used so they don't have to be recreated each time. Your lists don't seem to be too complicated (I'm testing the CERT's podcats list) but do seem to have a very very large number of items. This may be our problem, may not. On a menu screen, the user is generally going back-n-forth and the menu / icon / list screen doesn't need to re-load each time the back button is pressed. In your case, with these RSS screens, the user is going a few more levels, and when finally going back to the list (after listening, watching the content) the screen may be confused as to which cell goes where. Kind of losing track of it's order and messing up the interface. Again, just a hunch. Do this... a) Open the BT_screen_rssReader.m file in the BT_Screens folder. (do this in Xcode) b) Scroll down to about line 352 and look for this code: if (cell == nil) { c) Change that line to if (cell == nil || 5 < 6) { d) recompile, retest, see if it fixes it. This is an attempt to isolate the problem to the cellForRowAtIndexPath method. THis is the method that runs everytime a new list item needs to be created. I made that adjustment on this end and havn't been able to get it fail again, I hope you can too. This is a hack and not a good solution but will help us determine what may be happening. The idea is that your telling iOS to re-create the list item everytime (because 5 will always be less than 6). In other words 'if cell is nil OR 5 < 6, make a new cell' If this works, you shoudl be fine to leave the hack in your code because your list does not contain images, rounded corners, or other memory intensive things. You'll for sure want to test this on an actual device, not just a simulator. The devices have far less memory and the performance may be poor. a) Make the adjustment b) See if it works c) Post your results.

@ peter: Forgot to mention. The CISSP would be much better without using the tabbed layout. You only have one tab, what's the point? In the Layout area, set this as the home screen and dont' use tabs, this will also increase the performance of the app.

Hi David, thanks for your hard work! I have made the adjustments, saved, clean all targets, build and run, tried the RSS list, and.... nope, still isn't working. I even removed the if statement as a whole to execute the Init our custom cell lines aways, but makes no difference. I don't know the size of the list is the problem. Even a very small list, like in News, Information Week (just 6 entries) the problem exists. Just a thought: I understand from your description that the RSS list is redrawn when hitting the back button. That makes sense. But the behavior we see is that when hitting the back button, the RSS list if in perfect shape, all items are displayed properly. Only when scrolling down and up again the item disappears. I think this might be an important difference. So it's is more the behavior of a Selected item... Making any sense?

David, any luck? Thanks !

Hi Peter. Good nudge. I've spent a considerable amount of time on this and do have some insights but no fix yet. It's looking like the UITextView could be causing the trouble. Each item in the RSS list has a title (UILabel) Description (UITextView) and optional image. A UITextView is used as the description because it's multi-line and there are lots of different height / content variations. It's looking like the appoach is not so good! I'm not 100% sure this is the trouble but I've done extensive testing on lots of other 'could-be' things and have also found many online posts about this same topic. Apparently UITextView in a UITableViewCell is a bad idea? So... this does need to be fixed but I haven't figured out the best solution yet for the large number of users that are having no trouble and the few that are experiencing the troubles you and phaques are. Here's an idea... Because your RSS feeds to no use images, you could use a standard UITableViewCell instead of of the BT_cell_menuList cell. If this worked, you would be hard-coding the size and layout of the cell instead of pulling the configuration options from the screens control panel at buzztouch. Again, this is just and idea but it should work? If you have zero idea how to do this, let me know and I'll try to recreate your layout using the standard iOS cell instead of our customizable cell. Hope this makes sense.

Hi David, Many thanks for the amount of time you put into this, just great. I have zero idea how to recreate the layout using ObjC. I also have zero idea how much of your time I am asking when you recreate the layout. You have tons of other work to do, so it should be worth the investment for just one (maybe two) users. Just an idea: As a workaround for me, can't you just add an refresh/rebuild option somewhere in the code. In short: when hitting a rss item, next screen. Go Back, item gone after scrolling (being the problem). But when doing another back to previous screen and then re-enter the rss list screen, all items are fine. So when we could force a rebuild of the list somehow the symptoms are gone. Make sense?

Hi Peter: The refresh 'everytime' logic does make some sense but I don't think it's a logical solution, or even a good workaround. I say this because the list would start at the top everytime. Example: I scroll down the list a few items, below the fold, then choose a story. When I return, the list itself would be at the top again - seems confusing. Don't worry about the amount of effort it takes on this end to work through these kinds - it's what I do and I'm motivated to work through these and other gotcha's regardless of the difficulty of each thing. It's important that the software work as advertised, and, like I've said before, you guys are helping us far more than we are helping you ;-) I've already begun a few other implementation ideas on the menu-list-cells and will get back to it after reviewing a few dozen other pending / open questions.

Hi David, ok, keep me posted on this issue. When my app is ready for release in the real world, I will contact you for the latest status on this. Thanks !

Hi, I am also facing the same problem. Did you find a fix for this? Please let me know. My problem is very similar. I navigate to an RSS screen. I select a cell. It take me to another screen. I navigate back and every this is alright now. At this point, if i scroll the screen such that the cell i had selected earlier scrolls beyond the screen boundary and when comes back, there is nothing showing in the cell. Its all blank. Please help

Hi ManUnited, missing Van der Sar already :-) There still isn't a fix for this, I have learned to live with it, so the problem exists in my apps in the AppStore. Perhaps David reads this and have some magical solution... Bye Peter

Forgot about this post: Try looking at the BT_screen_menuList.m and BT_screen_rssReader.m files. See if they are using: NSString *CellIdentifier = [NSString stringWithFormat:@cell_%i, indexPath.row]; OR static NSString *CellIdentifier = @Cell; If they are using the static method, use the first method posted. Should fix it. Or, um, it has for some ;-)

Hi David, I looked at both files, and both do not use the Static method. (the static mode is commented out and the first method of your post is used) So no fix :-( Thanks anyway! Peter

Crap. The mystery continues. We'll dive beack in and see what we can find. Nudge this thread if you dont' see a resopnse in a few days?

Hi David, In my downloaded code, i had static and i changed it to what you suggested. But as peter mentioned, no luck. Issue still persists. Would it be possible that when we navigate back to RSS screen, we do a refresh of the screen. I think that would give us a work around.

I guess that would work but it's not a good solution in my opinion. If you did this the list would scroll to the top when you tapped back. It's crazy how hard this issue is to track down! I think the problem is with the BT_cell_menuList.m object. I'm working on a solution that does not uses a standard UITableViewCell (intead of the custom BT_cell_menuList.m cell) to test to see if that's the issue. I'll report my findings.

I also have the same problem... I was unable to find what might cause it. It would be nice to add an option so that a feed appears as read when coming back to the main RSS list, by changing the title's color for example. Maybe that would help get rid of the problem (or it might just be a stupid suggestion, I don't know...). Anyway, I hope someone will be able to find a fix :)

Sorry to bother everyone again... Has anyone found a fix? I've spent days looking for what might be going wrong, and haven't found a solution. The good point is that I learnt a lot going through the code :) (and that's what makes buzztouch such a great tool!). Of course, it's not that much of a big issue... but as a perfectionist (or a maniac ^^), I can't see myself submitting my app without taking care of this detail.

It's OK. There isn't a permanent fix for this (included in buzztouch). But...since you dug around the code a bit you may be able to get your head around this concept: The rows in the list are UITableViewCells. Specifically, the UITableViewCells come from BT_cell_menuList.h, .m. That file is a complicated sub-class of UITableViewCell. So, that's the file that' causing some trouble. If you look at the cellForRowAtIndexPath method in the RSS screen's .m file you'll see where this cell is instantiated for each row. You could use an iOS Built in UITableViewCell instead of the custom one and see if it changes anything. It's important to understand that some of the advanced options in the control panel may not work if you use a standard cell but for the majority of cases this is OK. There are several styles of built in UITableViewCells. One line, two lines, image, etc. Set the text and description and image of a built in cell and see what happens. We'll get back on a permanent solution when we get Android v1.5 done - more than full time keeping up with it's beta release ;-)

Thanks for your answer, David! I've actually been thinking about what you suggest, and I'll try to see what I can do with this when I have a bit more time ;-) Otherwise, I've found a solution to the problem, but an ugly one... Anyway, if anyone is interested, here's what you should do: In your file BT_screen_rssReader.m, at the end of the section //on row select (around line 472, after theDynamicScreenObjectToLoad = nil;), just add these 2 lines: [self downloadData]; [self hideProgress]; Thanks to that, the problem disappears (but that's an ugly solution)!