drupal hit counter
Jerry Huang | apps and developing apps

Jerry Huang apps and developing apps

Something about We The Drivers app

1. June 2019 16:52 by Jerry in Apple/iOS

What the app does

One of my apps, We The Drivers is made for Uber drivers to track latest surge around current location. The main reason that such app exists is because Uber driver app doesn't always give you the update surge info. Feedbacks from a lot of drivers show that the surge info is constantly intentionally out of date or inaccurate. In the latest version (of Uber driver app), the surge factor is simply removed. Why it's "intentionally"? Because the surge and pricing in the rider app show differently (or correctly). Why Uber does that? According to a lot of Uber drivers, they believe it's because Uber wants to attractive more drivers to get online; also don't want the drivers know the exact surge pricing. So this created a market for apps like We The Drivers to simply using Uber's API to get the most updated, accurate and transparent pricing info.

Apple app review

Before I publishing app to Apple's app store, I was involved in some commercial app development and publishing back then (even though I'm still from time to timeCool). I have learned a lot that how Apple is so stubborn in certain areas; how iOS developers' life is so miserable especially an app is submitted for the first time. When a project launch, iOS must be prepared in advanced and get ready for being rejected by the app review.

We the drivers was being rejected, for a few reasons, such as I can't use the wording "Uber" at app title but I'm ok to use it in description. Ok, make sense. Then they insist I have to provide a demo account as the app requires an Uber account to function. Well, things start to get interesting. Because my app uses Uber's public API and so rely on Uber's authentication. While I can't provide an Uber account because for security reason, when you log on your Uber account to a new device requires to receive a code via SMS. This common security mechanism is to protect your account and call "2 factor authentication". Eventually, after a lady from Apple's app review team called me, I finally got the app approved by providing a video showing how the app works.

But that's not the end of the story, after a few app update submissions, I'm getting rejected for the same reason in my latest submission. This time, Apple frozen my entire developer account for so-called "investigation". As you may or may not know, I'm running couple other apps under my name, so here is Apple's logic: because one of your apps is "suspicious", I will freeze your account until I figure out you have not done anything wrong. I'm not going to tell you how long I need for this investigation. However, until then, your operation is completely shut down meaning that you are not able to submit app update; you are not able to submit new app; even the app is not related to We The Drivers. And BTW, you still need to pay for the apple developer membership so that you maintain a valid membership status. 

Honestly I was shock. I was shock that America is a free country while I was being treated like that by an US giant company; I was shock that Apple is still that arrogant even after its market share being cut down (by Android) so much in recent years.

After I chased Apple couple times for status, Apple eventually released my account as well as the app update without any explanation after freezing my account for a few weeks.

There are a lot of other developers like me, when they do something apple doesn't like, their developer account is frozen or terminated by Apple. See this as reference: https://forums.developer.apple.com/thread/77865


Threat from Uber

When I thought everything should be settled, at least for a while, a few days after my apple account is released, I received an email from Uber. The whole thing looks like Apple and Uber are working together to stop me from developing this app. I don't have proof, and it's just my suspicion, but the timing, what a coincidence!

Unfortunately I cannot disclose what kind of "threat" I received from Uber, not just yet. But sometimes I'm really not getting it, We The Drivers is not the first app in its kind, definitely not the last, it's also not that famous, there are others in the market. Is it just me or other developers are in the same situation? If you are a developer is/was developing similar app, I would love to hear from you. Send me a message from "Contact" menu of this site if you would like to be in touch.


I'm freezing Apple and plan for the next move

When Apply suspected me or my app, they freeze my account. So when I suspect Apple is working with Uber and trying to stop me, I stop updating We The Drivers to iOS app store for the time being. The latest version on iOS is 1.1.7. Frankly speaking, it leaves me no choice. Besides, it's not worth it. From my app's statistics data, over 90% of users are from Android. I see no reason for me to continue dealing with Apple, so fuck you Apple!

For those Uber drivers that are still using iPhone, I may have to suggest you to use Android when online with Uber. Fortunately my app could runs smoothly on most Android devices, as long as it's not too old, couple years back should be just fine.

At this moment, I'm still opened and willing to compile with Uber's policies. The question is that would Uber be opened to let small individual app developer like me to continue? Or would Uber be opened to look into its transparent problems so that apps like mine will not have a market? If the answer for both questions is "no", I might take the whole app underground and make it free for everyone if I have to.


Re-using your SOAP in Xamarin .Net Standard

19. January 2019 22:01 by Jerry in C#, Xamarin

I have an old Xamarin Forms project that created couple years ago, by then, was using PCL as project template. The project initially was only for iOS but recently I need to support Android as well. For some reason, there is an runtime error as soon as the app launched. Long story short, I want to upgrade the PCL to .Net Standard 2.0. The project consumes a SOAP web service (asmx) also written long time ago. Even thought I manage to eliminate all compile time error after re-generating the proxy class. The WS call end up with the same exception as below:


Operation 'methodNameAsync' contains a message with parameters. Strongly-typed or untyped message can be paired only with strongly-typed, untyped or void message.

The issue is currently opened here as well:


After some research, I understand that there is no solution for that while I don't want to re-write my SOAP WS into REST api. I decided to write my own SOAP client by re-using the data/schema classes generated inside proxy class. Here is my soap client looks like:

public class SoapService 
private static T Deserialize(string xml, string ns= "http://home.jerryhuang.net/")
Message m = Message.CreateMessage(XmlReader.Create(new StringReader(xml)), int.MaxValue, MessageVersion.Soap11);
XmlSerializer xmlSerializer = new XmlSerializer(typeof(T), ns);
return (T)xmlSerializer.Deserialize(m.GetReaderAtBodyContents()); 
class RequestMessageBodyWriter : BodyWriter
private MessageBodyDescription bodyDescription;
private object[] parameters;
public RequestMessageBodyWriter(MessageBodyDescription bodyDescription, params object[] parameters)
: base(false)
this.bodyDescription = bodyDescription;
this.parameters = parameters;
protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
// Can't Dispose this xmlWriter, 'cause it will close 'writer'.
var xmlWriter = XmlWriter.Create(writer);
xmlWriter.WriteStartElement(bodyDescription.WrapperName, bodyDescription.WrapperNamespace);
foreach (var part in bodyDescription.Parts)
var dcs = new DataContractSerializer(part.Type, part.Name, part.Namespace);
dcs.WriteObject(xmlWriter, parameters[part.Index]);
private Message GetRequestMessage(string opName, params object[] para)
var serviceDescription = ContractDescription.GetContract(typeof(HomeServices.HomeServiceSoapClient));
var operationDescription = serviceDescription.Operations.Single(op => op.Name.Equals(opName));
var inputMessage = operationDescription.Messages.Single(msgDescription => msgDescription.Direction == MessageDirection.Input);
var bodyDescription = inputMessage.Body;
var msg = Message.CreateMessage(MessageVersion.Soap11,
inputMessage.Action, new RequestMessageBodyWriter(bodyDescription, para));
return msg;
private string GetUrl(string api)
return string.Format("https://yourWSURL/something.asmx?op={0}", api);
public async Task Login(string user, string pass)
var msg = GetRequestMessage("LoginAsync", user, pass);
var _httpClient = new HttpClient();
_httpClient.DefaultRequestHeaders.Add("SOAPAction", msg.Headers.Action);
var soapString = msg.ToString();
var response = await  _httpClient.PostAsync(GetUrl("Login"),
new StringContent(soapString, Encoding.UTF8, "text/xml"));
var content = await response.Content.ReadAsStringAsync();
var o = Deserialize(content);
return o;

That's it, I keep re-writing the method similar to Login. The implementation is to serialize the request and manually POST via HttpClient; then deserialize the response back to objects.

Generic MJPEG, JPEG and RTSP support

20. November 2016 03:38 by Jerry in IP CAM

A few months ago, 3 camera types shipped in an update of the app:

  • Generic MJPEG
  • Generic JPEG
  • Generic RTSP

The reason I added those camera types is that I received a lot of emails to ask for support for brand-less or small brand IP cameras, sometimes the users asked for video streaming support only. So instead of adding a lot of camera in the list, I created these 3 types corresponding to 3 different standard video streaming protocol. However, using these camera type requires the user (i.e. you) has some basic IT knowledge, or at the very least, you know your camera very well. More precisely, you need to know the streaming URL of your IP camera in advanced.

MJPEG or MJPG stands for Motion JPEG, it's a series of JPEG (frame) transferring within one HTTP connection (between your device and your camera). The MJPEG engine in my app is using the MJPEG streaming URL for video; while JPEG engine in my app is using a snapshot URL for video. Most MJPEG/JPEG URL is a standard http address like this one:


For above sample, please use following settings in my app:

Camera type: choose "Generic MJPG" or "Generic JPEG" as camera type (according what protocol is running behind the URL)

Hostname or IP: mycam.dyndns.org:8080/could/be/anything/here/sample.cgi?something=value

Port no: 8080

then username and password to log in your camera

and that's it!


Similarly, for RTSP, assume your camera's RTSP URL is this:


the setting will be:

Camera type: Generic RTSP

Hostname or IP: mycam.dyndns.org:554/whatever/1

Port no: 554

then username and password.


Please note that these 3 camera types is aimed to get your video working (and video related feature, such as recording), features like pan/tilt is not supported. And once again, I would like to emphasize that this is for advanced users, i.e. the people who are very familiar with the camera she/he own. If you have no clue or you can't understand any of above, the 3 camera types are probably not for you:) 

IP CAM Controller demo at BUILD

24. March 2016 04:23 by Jerry in IP CAM

I will be attending Microsoft's BUILD conference in San Francisco from March 30th to April 1st next week. I will also host a demo of IP CAM Controller from 1:30PM – 3:45PM on Thursday, 3/31, if anyone would like to meet me in person, you are more than welcome to join me at the Solutions Showcase area which is located on the first floor of the expo hall at Moscone West.

More info about BUILD: https://build.microsoft.com/

[update] some photos from the demo:)


new app, versions, history and others

7. October 2015 11:04 by Jerry in

IP CAM Controller is now supporting Windows 10:) To indicate this is a major update, the version no bumps up to v10.x.x, by following the example of Microsoft.


By using the latest technologies (UWP), the app now provides universal experience for phone, tablet and desktop, the only major difference would be just screen size, the rest should look and feel and work as the same among platforms, devices. Microsoft is finally taking us to the next level: write once and debug every whereLaughinglol


Another reason I like about the new SDK is that a lot of open source components start to be available on UWP, such as OpenSSL, FFMPEG. By taking advantage of that, the new IP CAM Controller is finally able to support H.264 which is a streaming protocol support by most newly made IP cameras. In the app, you will see a "HD" button in the control panel if your camera has support for H.264. 

I wouldn't say I'm proud but by looking back the past few years, I started the app with Windows Phone 7, for a series of very simple but interesting reasons - my first son born; I brought my first IP camera; I was using a pocket PC runs Windows Mobile 6/6.5 with an app that support "click to center" (I think the name should be ViewCommander); then I switched to WP7 and there is no app at the time that support tap-to-center, I decided to make my own. And then users (yes, you!) started to ask for new features, support new cameras and even new platforms. After breaking through milestones like audio, android, H.264, iOS, look at where we are now:)


A list of milestones:


  • v10 for Universal Windows Platforms, i.e. Windows 10 desktop, mobile, tablet
  • v1.x for Windows 8.1 desktop and tablet
  • v3.x for Windows Phone 8 and 8.1
  • v2.x for Windows Phone 7 (discontinued)


  • v1.x


  • v1.x

Last but not least, I would like to take this opportunity to thank Sam (linkedin) and Zexu (linkedin) who I work with on other platforms.

volunteer wanted

20. September 2015 00:14 by Jerry in IP CAM

I'm working on the new version of IP CAM Controller for win10 and windows 10 mobile (aka p10). It's a kind of in the final stage. There are  a lot of things changing in the new platforms, and so I need a few volunteers help me to translate the app into the languages that already supported in my WP8 version. Please kindly drop me a note by clicking this link: 


It would be better if you have a PC installed Windows 10 to test out the new app.

IP CAM Controller is FREE on Windows for a day!!

10. July 2015 12:51 by Jerry in IP CAM

By cooperating with myAppFree.it, IP CAM Controller for Windows Phone and Windows Store (8.1 and onwards) will be free for 1 day, starting at 11 AM July 11th GMT.

Terms and conditions:

  • The original price of the app is US$1.99. The price will be $0.00 during the promotion while it will be restored to original after the promotion is over. However, if you downloaded the app (which is free) during the promotional time frame, you own the app for lifetime.
  • Please note that we are selling 2 types of products in the app, one is mainly for removing ad - this is the one we set free in this promotion; while the other type is unlimited audio per camera brand - this is not included this time.
  • This promotion is applied to Windows Phone and Windows Store only, iOS and Android are NOT included this time.


 Get it on Google Play

Next stop: win 10

I wrote a blog post (here) last year whether I should or should not upgrade my development from WP8 to WP8.1, and my conclusion was "no go". Basically it's not worth it. I believe that I made the right decision back then, because otherwise I will fall into similar situation again, Win/WP8.1 -> Win10.


I have been keep track of MSFT's app development for a few years now, and honestly I'm tired and a bit sick about that. Because every time MSFT announce something new, something they are really excited about, developers need to drop something they had been familiar with and rewrite the codes. Even worse, the "excitement" is short, the "new thing" becomes worthless in just maybe 1 or 2 years (such as WP7, Silverlight). Maybe that's the reason WP's market didn't go any further in the past few years - At first, MSFT pissed off customers (WP users) by announcing WP7 cannot upgrade to WP8, and then MSFT pissed off developers by keep introducing new stuff without backward compatibility. Myself for example, I brought 3 lumia 800 phones (the price of 800 is almost the same as iPhone back then) at the beginning, when lumia 930 launch, I hesitated and eventually I went with lumia 720 and half year ago I switched to iPhone. I wouldn't call myself a loyal user of MSFT but I start using MSFT's phone since Windows Mobile 5. I don't know too much about marketing, but this is really sucks!


Being said that, the good thing is that MSFT seems to aware of the problems they are having. I attended the Build Tour in my city yesterday. They start to demonstrate MSFT technologies on competitors' products, such as MacBook and iPhone; and I'm sure you heard of MSFT start to attract Android and iOS developers by supporting them in the new VS2015 (probably because they are losing their own developers??LOL); MSFT is having an open-mind more than ever. This is good but this is far from enough and I believe they know it.


Win10, after a few years' struggling, this piece of ....... thing looks decent to me, from a developer's angle of course (I heard some noise about the UI changes BTW). But on the other hand, as usual, every upgrade is painful, especially true for WP developers. I would rather not going too much details here, you may have a taste by reading this post: http://blogs.msdn.com/b/lucian/archive/2015/06/09/win10-apps-in-net-porting-from-8-1-universal-to-win10.aspx

In short, it's not that bad by comparing transitions in the past, because most codes and XAML should be still useful while for 3rd part controls just give it some time, they will be supporting win10 sooner or later. At the very least, the underlaying frameworks are not being changed; they are not turning the framework up side down this time like what they did in Silverlight to WinRT. But I feel lucky and happy that I didn't go for WP8.1 last year because that is simply not the final stop. While for this time, I probably will go for win10:)


PS. yesterday's Build Tour, free entrance, free foods, basically free of everything and you could get a nice Build t-shirt at the end, my opinion to MSFT would be a lot more depressed if it's not because of that:))))))

2 way audio camera testers wanted

24. April 2015 21:22 by Jerry in IP CAM

As you may or may not know, last release of IP CAM Controller on WP and Android have 2 way audio support for Foscam. This has been sitting in my TODO list for quite a long while and finally getting somewhere:)


To support more cameras, I will need some volunteers whose camera is following brands:


Please note that I will need access to your camera and might require admin permission for investigation. Please click here and leave me your camera access info if you would like to participate. You can use following as a sample:

Camera brand and model: TRENDNet 862IC

Camera type using in the app: TRENDnet TV-IP 862IC

Host: www.mycamera.com

Port: 80

Username: temp

Password: SomeSecurePWD