A while ago I wrote a post on adding AdDuplex ads to your App Studio App. In that post I added AdDuplex as a fallback option should the PubCenter ad control fail to display an ad. At the end of the post I noted that AdRotator would be a better option for supporting multiple ad providers, but at that time AdRotator did not support Universal Windows Apps. Since then I joined Simon Jackson and worked on adding Universal App support for AdRotator, time for a new tutorial post!
I love technology podcasts, and subscribe to several of them. With my long commute I honestly don’t know how I would live without them. The Windows Developer Show, .NET Rocks, MS Dev Show, Windows Weekly and Entreprogrammers are some of my favorites (some of which I’ve even had the pleasure of being a guest on 1 2 3). AppBizDev is another podcast which belongs on the list of my favorite shows. But unfortunately there hasn’t been a new episode of AppBizDev in a little over a year.
A few weeks ago Microsoft announced Windows Ad Mediation. Their own solution to the problem that the Open Source AdRotator project has helped app developers with since the early Windows Phone 7 days. Since both AdRotator and Windows Ad Mediation are trying to fix the same problem I wanted to look at the different scenarios for Windows and Windows Phone app developers and see which solution made sense for you.
I recently attended a MMADNJ user group session by Nick Landry covering App Studio. Nick created a new app using the App Studio tools and published it by the end of his talk. I followed along creating my own app, Destiny Hub, which was published the day after the user group session.
App Studio gives you the options to add Pubcenter ads to your App Studio creation, but I wanted to have AdDuplex ads as well. Having AdDuplex ads in my app will allow me to advertise my app and get more users for Destiny Hub. So today I’m going to go over the process I went through to add the AdDuplex controls to an App Studio Windows 8.1 and Windows Phone 8.1 app.
This year at Build I went to a few sessions covering the new Background Task infrastructure available for Windows Phone 8.1 Apps. The Microsoft Program Managers running these sessions all echoed a common theme: you should write your background task code in C++.
I’ve written a few times in the past about the importance of URI schemes for Windows Phone 8 apps. I also had the pleasure of working with the developers of Bringcast and P|Cast to create a podcast player URI scheme and a helper library to work with it.
Today Mark from the Bringcast team let me know that the PodcastWP library didn’t work properly with Universal Windows Apps. There are apparently a number of differences in the way URI protocols are handled between Windows Phone Silverlight and Universal Windows Apps. In today’s post I wanted to go over some of those differences and show the changes made to the PodcastWP library to support them.
I answered two stackoverflow questions last week that revolved around the topic of how to call C# methods from your C++/CX WinRT Component code. There are a lot of reasons why you may want to do this. There may be a 3rd party tool with a C# API that you want to make use of from your C++/CX code, Analytics libraries like Flurry or Google Analytics as one example. Or maybe there are certain platform APIs that are available in C# that aren’t accessible from C++/CX (this problem may go away with universal apps, but it is a common problem when looking at the Windows Phone 8 Silverlight API).
I’ll be speaking at the Microsoft Mobile App Developers of New Jersey (MMADNJ) user group this July 15th on the new Background tasks of Windows Phone 8.1.
Last month at the MMADNJ user group Nick Landry (@ActiveNick) started doing a ‘show & tell’ segment for published app developers to share some of their work. I talked about Car Dash and shared some tips and free resources I used to make the app successful.
Today I wanted to go into some more details on some of these resources. There a lot of great tools available, and many of them are free for independent app developers.
The Windows Phone dev center allows you to view crash reports for all of your Windows Phone apps. For C# apps the feature works great, it allows you to see a full stack trace of the exception which should give you enough information to fix the crash. With C++ Apps the stack trace only gives you the memory address of where the exception occurs though. In this post I’ll show you how to find the function where the crash is occurring in your C++ code from this memory address.