drupal hit counter
Jerry Huang | apps and developing apps

Jerry Huang apps and developing apps

We the drivers requires input new minimum fare of a trip to work properly

13. January 2023 10:46 by Jerry in

Please go to app store/play store to update the app to latest version first


Since early Jan 2023, Uber has stopped providing surge multiplier through its api, and so all 3rd party apps such as mine (We the drivers) are unable to provide direct surge multiplier no more.

In light of this, I have published a new update urgently, to calculate the multiplier by: 

surge multiplier = current price / base price (aka minimum fare of a trip)

The down side is that you will have to input the base price of each ride type (option) every time the fare has update. This setting looks like below screenshot, type in the minimum fare in your local currency of each car type/ride option; once everything is set, click the "Save your input". 

If you app version is v1.2.1, follow below steps:

Once base price is set, all your saved locations (pins) will be using Base Price 1 for calculating multiplier by default. In some cities, different area or special venue (such as airport), is using different pricing structure, you can configure up to 4 set of base price; and then each pin/location can choose its own base price setting.

Having said that, I will never know when the next restriction would come. As a result, I had stopped the 3-month subscription and keep the 1 month subscription only. I also encourage you to switch to 1 month subscription if you are currently purchasing 3-month. As we never know when the app might not be able to work. In order switching to 1 month from 3-month, you can cancel the 3-month subscription first from App Store/Play Store, the premium state will remain until the last date of your subscription; and after the subscription expired, you can purchase 1-month. 

I'm putting some FAQ here, will keep update the list:

  • Surge accuracy: there might not be the exact surge but very close to the reality. This is the best result we could get from what we have. The calculation should still give you a sense how much higher than usual and so leading you to the popular area. 



請先前往App Store/Play Store更新到最新版本。

由2023年1月開始,Uber已經停止提供加乘倍數。所以所有的第三方apps包括We the drivers都無法提供直接的加乘倍數。


倍數 = 當前車資 / 最低車資


雖然倍數可以通過這個方式計算獲得,但我永遠也不會知道下一個問題/限制會是什麽以及什麽時候到來。因此我決定取消 三個月高級版的 訂閲如果您正在使用三個月訂閲,我也鼓勵您現在就轉到一個月。您需要先在App Store/Play Store中取消三個月訂閲,您依然可以使用到訂閲到期的時間。當三個月到期后,您就可以在app裏面支付一個月訂閲。



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/

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:))))))

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