Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts

  • Danilo 9:09 am on April 6, 2012 Permalink | Reply
    Tags: 7.1.1SDK   

    I’ve just received this info from Microsoft:

    With the upcoming release of 256-MB devices, Technical Certification Requirement 5.2.5 will be enforced for those apps that exceed the 90-MB RAM for usage or 256-MB memory limit. If your app memory exceeds these specifications, please be sure to install the Windows Phone SDK 7.1.1 Update and include the Opt Out feature in your application manifest file to indicate that it will not function properly on the 256-MB devices. You can use the DeviceExtendedProperties and DeviceStatus classes to query the amount of memory that your application is using, and to adjust behavior based upon the memory available on the device. There is more information found in this article, Developing for 256-MB Devices, to develop your app and ensure it works on the targeted devices.

    I will test the app on a 256MB Emulator today. Will post here the results of the test.

     

    • Danilo 11:09 am on April 6, 2012 Permalink | Reply

      The app works pretty well on devices equiped with 256MB of RAM, but the memory limit can be easily reached by using the post preview feature, that uses the “in-app browser”. We need to investigate further, i’ve added some methods to keep track of RAM usage in [295]

      • Dan 1:34 pm on April 6, 2012 Permalink | Reply

        Does the app just quit out when it reaches the memory limit?

        • Danilo 2:37 pm on April 6, 2012 Permalink | Reply

          No, the simulator screen went black but the app was still there. I’ve hit the back button and the app kept working fine on the posts list. Anyway I tested the app again, and seems that the memory usage never reach the 96Mb limit.
          The browser screen is the section of the app that consumes the major amount of memory.

      • Max Cutler 1:22 am on April 8, 2012 Permalink | Reply

        Keep in mind that the app’s memory usage is also dependent on the quantity of content on the user’s blog(s), since we store the entire dataset in a file and deserialize/serialize to/from memory on every app load/exit. Essentially, memory = XAML + images + code + (blogs * (comments + posts + pages)).

  • Dan 10:10 am on February 4, 2012 Permalink | Reply  

    Happy birthday @maxcutler :)

     

  • Isaac Keyet 12:15 am on January 24, 2012 Permalink | Reply
    Tags: error log,   

    I see this error a lot in bug reports. What are likely reasons for something like this to show and how can we prevent it?

    System.Net.WebException: The remote server returned an error: NotFound.

     

    • Max Cutler 12:32 am on January 24, 2012 Permalink | Reply

      We talked on skype, but for the record:

      Looks like #70, which was fixed in [251]. So hopefully this will stop happening in the new version.

  • Dan 8:48 pm on January 20, 2012 Permalink | Reply
    Tags: ideas,   

    Uploaded the XAP just now to the App Hub! Nice job guys, keep your fingers crossed :)

    Some ideas we’ve had for the next version of the app:

    • Improve the wonky post editor (jerky keyboard/field focus issues, button taps when scrolling)
    • Add support for resizing images to user defined sizes
    • Add Post Formats and Post Password
    • Video upload?
    • Upload media to pages
    • More UI tweaks
     

  • Dan 3:14 pm on January 18, 2012 Permalink | Reply
    Tags: failed uploads, network timeout   

    The app failed miserably at uploading 3 pics in a post when I was out on 3G today. I think it’s not retrying the upload if the connection fails. The other apps try at least 3 times before they give up.

    http://windowsphone.trac.wordpress.org/browser/WP7/WordPress.Model/XMLRPC/XmlRemoteProcedureCall.cs#L218

    It looks like HttpWebRequest doesn’t support retries natively, but we could just keep a counter and retry the same upload again if it fails. @maxcutler do you have any ideas here?

     

    • Max Cutler 3:22 pm on January 18, 2012 Permalink | Reply

      That’s right, you’d have to manually do retries. HttpWebRequest represents only a single request attempt. Sounds like a good candidate for some utility methods, as that type of behavior is likely desirable in other places too.

      Can you tell what failure condition HWR was giving you? You should be able to capture data connection failures and notify the user to retry upload later once they are connected to 3G or wifi (if that is indeed the issue you were encountering).

      When I was playing with the app yesterday, I noticed a bunch of null exception errors related to the post date field and the category selection screen. Have you resolved those? When debugging, be sure to have “break on first-chance exceptions” turned on for CLR exceptions.

      • Max Cutler 4:03 pm on January 18, 2012 Permalink | Reply

        Updated to latest code and I’m not seeing those null exceptions anymore.

        @danroundhill, can you add the form field background color/effect to the publish date fields? Right now they look like labels and it’s non-obvious that you can press them to enter an edit mode.

        • Dan 4:04 pm on January 18, 2012 Permalink | Reply

          Sure, I’ll take a look.

        • Danilo 4:05 pm on January 18, 2012 Permalink | Reply

          Updated to latest code and I’m not seeing those null exceptions anymore.

          I fixed a bunch of issues related to posts/pages/comments “datetime” yesterday. Let me know if you notice something strange.

    • Isaac Keyet 6:24 pm on January 18, 2012 Permalink | Reply

      There was a bunch of people using WindowsPhones at the WC I went to last week, and the #1 complaint about the WP app was how poorly it handled media uploading, to most it sounded like it was practically useless. If we can somewhat fix this I think we just made people 2x happier with this release!

      • Danilo 9:03 am on January 19, 2012 Permalink | Reply

        Most probably we should spend an iteration working on the media section of the app.
        There are room for huge improvements: http://windowsphone.trac.wordpress.org/milestone/1.4

        One more thing, when the user takes a picture, or selects a picture from the library, I think we should show the “image resize popup” like the iOS app. At this moment pictures are uploaded at full size and scaled by using CSS code.

        • Dan 9:17 am on January 19, 2012 Permalink | Reply

          You’re right! No wonder my uploads failed so much. Average picture size on my device is 900k.

  • Dan 3:56 pm on January 16, 2012 Permalink | Reply
    Tags:   

    Once @rhc3 finishes up #60, let’s code freeze and take 2-3 days to run the app through the test plan. For the most part we can just use the iOS test plan and skip steps that don’t apply.

    This probably means we should go outside or something to post over 3G/EDGE!

    It’d be super if we could submit on Thursday afternoon GMT.

     

    • Isaac Keyet 5:15 pm on January 16, 2012 Permalink | Reply

      Sounds good. Definitely test the app in areas with poor connectivity if you can!

  • Dan 5:33 pm on January 12, 2012 Permalink | Reply
    Tags: ,   

    I was able to significantly reduce the load time of the panorama by removing the stats pane and moving it into its own page that is accessible from the Actions pane. The load time is just under 2 seconds now. For the new Stats button, I made it span across the width of the panel just like the settings button used to.

    Everyone ok with moving the stats pane off of the panorama UI?

     

    • Max Cutler 5:58 pm on January 12, 2012 Permalink | Reply

      Sounds good to me.

    • Taylor Brazelton 4:37 am on January 13, 2012 Permalink | Reply

      I really don’t use the stat’s page much so if it’s slowing down the load time of the actual application I say move it on over to it’s own page. I’d rather access stats via a new page anyways. Inside the panorama it seems a bit squished by the margins.

    • Crystal Awards 5:30 pm on March 13, 2012 Permalink | Reply

      That’s good to me.

  • Max Cutler 5:05 pm on January 11, 2012 Permalink | Reply
    Tags: design, metro   

    For the other devs who aren’t as familiar with WP7 and Metro design, I curate relevant links that you might want to check out:

    http://www.diigo.com/user/Maxcutler/metro%20design

    I think Jeff Wilcox’s “design guide for developers” is a must-read, and the “31 Weeks…” series has been outstanding so far too. The rest is good reference material if you have time.

     

  • Dan 3:13 pm on January 11, 2012 Permalink | Reply
    Tags: pivot   

    Converted the Panorama to a Pivot today It… 

    Converted the Panorama to a Pivot today. It shaved two seconds off of the loading time vs. the panorama! It still takes about 2.5 seconds to load on my HD7 which I still think we could improve upon. Overall it feels very snappy to move about the Pivot. I changed a few things with the layout:

    • Used a smaller, standard header text for the blog name that is in all caps. This follows the UI guidelines for a pivot.
    • Moved the loading indicator up to the top of the page above the blog title.
    • Made the dates in the post/page lists blue, I think it adds a nice touch of color.
    • Tweaked the stats chart a bit so it looks more in line with the rest of the content, it was too wide and took up to much of the right margin.

    @ievolver – thoughts on the UI?

     

    • Max Cutler 4:07 pm on January 11, 2012 Permalink | Reply

      I think I’m a -1 on this change. The performance increase is nice, but it’s a violation of a ton of Metro design principles. I’ll write up a longer response after I return from a meeting, or perhaps you’ll be on Skype and we can talk it out?

      • Dan 4:22 pm on January 11, 2012 Permalink | Reply

        I’m around for 40 more minutes or so!

        • Max Cutler 4:31 pm on January 11, 2012 Permalink | Reply

          I just got back and will be online for the next hour. My Skype is max.cutler, it should be faster to talk than for me to try to type it all out (though I can do that too afterwards for the record).

      • Dan 5:02 pm on January 11, 2012 Permalink | Reply

        Some notes from our call for the others:

        • The pivot UI doesn’t really make sense here because it is intended to be used for viewing things that are related to each other. A better example where we could use it is for viewing Posts by their status. One view for Published, one for Draft, etc.
        • If we’re looking to increase performance on the existing panorama, it may be better to move stats as a button on the Actions view that loads as a separate view. Also loading less data would probably help as well. Research needed here.
        • We talked about doing away with the first view in the app where you select your blogs. The People app has a good example where you can filter it by social networks.

        So it sounds like keeping the pano for now is best, and let’s see what we can do to increase the load time with it. I’ll revert my changes in SVN.

        • Isaac Keyet 11:24 pm on January 11, 2012 Permalink | Reply

          I’d argue that everything is related, it’s all you can do with your blog. A panorama view might be a better fit still, but I don’t think this is too bad.

          I’m all for moving the blogs list if we can.

          Actions dashboard has always been a little odd in these types of UIs, we could probably move all actions to individual screens in the panorama/pivot, and put blog settings in the blogs list only.

          • Max Cutler 11:47 pm on January 11, 2012 Permalink | Reply

            By “related”, it really means “filters on the same dataset” and not really “distinct-but-conceptually-related”. If you look at the built-in email or music or many other 1st party apps, you’ll see “proper” uses of Pivot for filtering datasets (e.g., Unread vs Read vs Flagged for email).

            Dan and I talked about just trying to get some simple performance wins on the existing panorama design, and then in a future release undertake a more sizable effort to create new pivot screens for each of the data types and further streamline the panorama.

            • Isaac Keyet 11:50 pm on January 11, 2012 Permalink | Reply

              Makes sense! I fully agree that it makes more sense for showing posts depending on statuses, for instance. Comments, same thing.

              Also a very good opportunity to replicate the core UI design princples in terms of screen sorting (Comments screen has All, Pending, Approved, Spam, Trash).

  • Dan 9:01 am on January 7, 2012 Permalink | Reply  

    A few of us are going to take on the app next week, mainly a bug fix release with a few new things thrown in if we have time. I went through the trac tickets and changed their priorities to what should be worked on. Anything that is blocker or critical is what we’ll work on:

    http://windowsphone.trac.wordpress.org/report/1

    If we can take care of those quickly, maybe we could take a look at Max’s post and start working on some of the UI changes. Maybe we could change the panorama to a pivot control, which should greatly speed up the delay when tapping the blog name in the blogs list.

     

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.