Closed christerdk closed 12 years ago
How looks the process of getting preview images? Can we use UriSmallImage
First of all, check this out :) The URL for the URISmallImage is: http://malmofestivalen.smugmug.com/photos/i-mHMHGHR/0/210x500/i-mHMHGHR-210x500.jpg But try to exchange 210x500 in the URL with for example 21x50. Yes, they're re-scaling on demand - good to know! :)
As I see it the "i-mHMHGHR" is the key for the file and therefore all we really need. To keep the app speedy and also to ensure less client faults, I would prefer that we create another column in the DB containg this key. Then, in the app, we can put together an correct image URL according to our specific needs. Good with you?
I've asked around, and form what I've learned the de facto approach for doing this is to keep a list of images to load (for example max 10). This ensures that the app is not swamped with the user scrolls over a lot events very quickly.
Sub-tasks that I can identify - with suggested work delegation:
Are you up for that?
PS. The DB centric and not API centric approach has been chosen to ensure speed (when many people are gathered and network load is high) and also to make sure, that the data used in the app is consistent (invalid data has occured, unfortunately).
Ok, just a follow up after I've tried importing 50 events. The URL's are not all following the same form, in fact they're quite varied.
I see two options:
or...
One means more data in the DB, the other means hacking together a string from existing URL. Which do you prefer? ;-)
I think if we follow the DB centric principle of the applicaiton, the thumbnails should be in the db, because it will minimize network traffic. Especially important when many people use 3G connections at the same time. What do you think?
Yep, I agree. I actually have a little time over right now, so I can brew the new DB structure and fix the import. I'll give you a ping when I'm done...
Updated DB structure and import now. Acts now has a UriSmallImage, which is also included in the events view.
I've created a "feature_1" branch wherein the changes have been put and I expect us to use for development of this feature.
This is inspired from the way we use feature branches on my current project. However, if there's any github de-facto style that I'm unaware of, I'd love the feedback (i'm new to github). Then we can adjust for future features.
To get some data to work with you can run MalmoFestivalDataFetcher2011 (dotnet folder). Check comments at the Main method for prerequisites. In debug mode, only 50 events are imported.
Great! To me github as a collaboration platform is new as well. I'll try fork and pull model. A branch for a feature, why not?
Yep, cool. Minimal friction. And yes, I'm used to use branches to isolate major changes. "It works..." ;) Please keep me posted, and let me know if you have any questions or get stuck or something...
I get a strange error:
But it works when I run curl http://api2011.malmofestivalen.se/json/category
I must have been some hickup. Now it works normally
Oh, btw, when you're developing pelase set Settings.IsDebug to true. This, among other things, means that no data is sent to Google Analytics... :)
I noticed that. When isdebug=false the app crashes.
Could I ask you to create an issue on this, describing when and under what circumstances the app crashes with debug=false? Then I'll look into it... On Apr 16, 2012 8:23 PM, "Anatoly Mironov" < reply@reply.github.com> wrote:
I noticed that. When isdebug=false the app crashes.
Reply to this email directly or view it on GitHub:
https://github.com/christerdk/Malmofestivalen-for-Android/issues/1#issuecomment-5158868
I'll do that
It looks pretty good now. You'll get a pull request soon.
When showing search results, current and upcoming event and other lists with events, it would be very nice with a thumbnail images where available.