Just Purchased the “HTC EVO V 4G” Phone…

The kid got a new phone yesterday – “HTC EVO V 4G” from Radio Shack, under a Virgin mobile plan.  A sweeeeet Android 4 phone with a “3D Imaging” camera (two side-by-side cameras really) and a 3D display. No – I have not played with the phone – the kid scampered off after it was activated…

Since this was a no-contract plan, we paid the $299 retail. We are going with the $35/mo with 300mins talk, unlimited text, and “unlimited” data plan.
I told the kid about data throttling, so she will be tight with her data budget (FB updates and such).
We feel OK about using Virgin as a carrier because of the price, we hear they are riding on the Sprint antennas, and Sprint is still busy building out the network around here.
Coverage is already fairly good, and more antennas will just make it better (college towns are so convenient for that…)

And yes – we broke our normal pattern of making her pay for these things herself – we paid for it (we promised as part of moving away from her friends…)

Advertisements

SUP on Android – Can Use Server Name Rather Than IP Address

Just noticed this on the SUP 2.1.3 client on Android.

Previously, we had to supply the IP-Address of the server rather than the more friendly server name.  It looks like that has been fixed and you can enter the server name.  I also had to use the fully resolved domain name, but I don’t know if that is because I am a VPN away from the server.

Reference:
https://reedteknik.wordpress.com/2011/11/06/uninstall-reinstall-a-package-on-android/

Blast From the Past – Same PBL in Different Targets

This PowerBuilder shortcoming popped up again in some emails this week…
The issue – having the same PBL in different targets (all in the same solution).
We first discovered this problem ages ago (even before ‘targets’ existed) – where one PBL is shared between different applications.

The cause of the issue is that the compiled P-Code (stored with the PBL) is dependent on the other PBLs in the target (the code generated depends on its ancestors in the inheritance tree).  IOW – the P-Code became slightly application and environment specific.

The result – sharing that P-Code between different targets, with possibly different ancestors, will lead to difficult/impossible to debug runtime errors. Needless to say, this led to a long history of customer issues…

However – if the ancestors were the same (and same order!), and if all the applications had the same compiler switches, sharing a PBL between targets would work.  Unfortunately, there is that one time where something was changed, and the system would be inconsistent.  This is that difficult/impossible to debug runtime error.

In PB.Net – we wanted to relax this distinction, but we ran into the same code generator issues.  The intermediary code and other cache information is stored in the PBL directory, next to the SR* files (in the ‘obj’ directory) hence locking in a target dependency (sigh).
There was some reason (I don’t remember what) the compiler guys wanted the files in the same directory structure rather than a parallel directory somewhere else (I can imagine a host of housekeeping logistics there, so I can sympathize).

One other thing – PB-Classic would attempt to prevent you from having the same PBL in multiple targets, but its checking was quite imperfect.  This checking was improved in PB.NET (having a fresh slate makes those things easier).

In short – don’t share PBLs between targets.