Get ready today. Business customers will soon be able to buy your apps in volume. Click through the latest Paid Applications Agreement so that your apps will be offered for sale when the Volume Purchase Program is available to businesses.I'm loving the use of the words 'Click through'. It seems obvious that even Apple accept that nobody actually reads any of their terms and agreements. Laughable if it weren't true.
Thursday, 14 July 2011
Apple Volume Purchasing for Business
To quote the email I just received from Apple Developer (via the iOS Developer Program):
Wednesday, 22 December 2010
HTC Google Nexus One Desktop Dock
I purchased one of these with my Nexus One earlier in the year but have not had the time to play with it fully. Now that I have I would strongly suggest others not to bother!
As soon as the phone is put in to it, as the sales material says, the Clock App automatically launches. Which is fine. If it were not for the fact that with mine the Clock App keeps on re-launching itself when I'm trying to run other apps. And it's not even like it's a timeout thing. Sometimes I'll only get a few seconds on the home screen and then the Clock App will run all by itself! I suspect this could be related to the contacts on the bottom of the phone and the dock briefly breaking contact and then reconnecting again. If this is the case then this device is a non-starter as there's no way for the user to fix this themselves. The contacts are tiny and they don't plug together - it just relies on the weight of the phone to keep it in place.
I do like the fact that the phone starts charging when in the dock. I also like the fact that audio is redirected to the back of the dock. I should also be able to take such usability notes as a given!
I'm less happy with the fact that Bluetooth automatically switches on when the device is in the dock. And if you then turn it off then it switches itself back on a few seconds later. I do wonder if bluetooth is maybe used to get the audio to the dock (as there are only three pins at the bottom).
The general impression is that this dock is a last minute hack (something I suspect HTC do a lot!). And a not a very good one. Very disappointing.
The Model ID of my dock is CR B410 with P/N 79H10032-00M. My phone is the Google (HTC) Nexus One running Android 2.2.1.
At some point I need to write some words about my experiences with the Nexus One screen (now twice repaired at my expense by HTC for cracks)... for another day...
As soon as the phone is put in to it, as the sales material says, the Clock App automatically launches. Which is fine. If it were not for the fact that with mine the Clock App keeps on re-launching itself when I'm trying to run other apps. And it's not even like it's a timeout thing. Sometimes I'll only get a few seconds on the home screen and then the Clock App will run all by itself! I suspect this could be related to the contacts on the bottom of the phone and the dock briefly breaking contact and then reconnecting again. If this is the case then this device is a non-starter as there's no way for the user to fix this themselves. The contacts are tiny and they don't plug together - it just relies on the weight of the phone to keep it in place.
I do like the fact that the phone starts charging when in the dock. I also like the fact that audio is redirected to the back of the dock. I should also be able to take such usability notes as a given!
I'm less happy with the fact that Bluetooth automatically switches on when the device is in the dock. And if you then turn it off then it switches itself back on a few seconds later. I do wonder if bluetooth is maybe used to get the audio to the dock (as there are only three pins at the bottom).
The general impression is that this dock is a last minute hack (something I suspect HTC do a lot!). And a not a very good one. Very disappointing.
The Model ID of my dock is CR B410 with P/N 79H10032-00M. My phone is the Google (HTC) Nexus One running Android 2.2.1.
At some point I need to write some words about my experiences with the Nexus One screen (now twice repaired at my expense by HTC for cracks)... for another day...
Thursday, 14 October 2010
Motorcycle Commuting
Things have been a little busy recently - finding a new job and more. So I've not found time or inspiration to write much on here. While I was walking back from work today I got to thinking about one of the alternative options for making the journey... namely motorbike.
Living in Chelmsford (Essex) and now working in Oxford Circus (Central London) I've opted to introduce 8 miles of walking in to my working day. The biggest walk being the 45 minutes between Liverpool Street Station and Oxford Street. With a train in the middle. And a walk from home to Chelmsford Station to boot. It takes quite a while. How long it will last I do not know.
A simpler alternative would be to get back on a motorbike. A rattle down the A12 and then battling the urban streets.
The problem is that I recently sold my motorbike after coming off last year in London when commuting to one of my client sites. I had done the journey many times and had become somewhat used to it. Someone pulled out in front of me from behind a station vehicle in queueing traffic and I was knocked off at less than 15 miles an hour. Still managed to dislocate my shoulder and fracture my humerus in four places though!
I had been motorcycling for two years by that point so was certainly comfortable with my machine (a Honda TransAlp XL650V for those who are interested).
The problem is that as soon as you take a motorbike in to a busy urban environment full of commuters you raise the level of risk enormously. To fully take advantage of your mode of transport you need to duck, dive, filter, overtake and generally 'zip' about. It is possible to do all of this safely as long as you concentrate on what you're doing and look / plan ahead.
What you cannot plan for is what the other vehicles, cyclists and pedestrians do around you. My accident happened because the van driver I was filtering past had flashed the driver who knocked in to me to tell them to pull out of a junction in front of him. What he had not done is check in his mirrors for motorcycles or other overtaking vehicles. As it transpired the lady who hit me had only recently passed her test (3 months I think she said) and so had assumed all would be clear and had literally spurted out in front of me. I remember grabbing a handful of brake (no ABS), feeling the back wheel lock, the bike swerve and then reaching my arms out in front of me to try and stop the pavement looming. There was no damage to her car or anybody else at all. Just me and my bike.
I get really annoyed now when I see scooter and motorcycle riders with inadequate clothing or footwear. I had the proper gear on and still managed to injure myself pretty badly.
Some might say that you can ride a motorbike without filtering and then you will be perfectly safe. I disagree. In fact I hear quite a lot of stories of motorcyclists who have braked to a stop but had the vehicle following them not stop in time and thus crash in to the back of them. Potentially fatal.
And I've not even looked at the danger of riding a motorbike at speed on a fast A road or motorway. If an engine ceases or a tyre blows at that speed I dread to think of what the consequences can be. I generally feel riding on these fast roads feels safer in terms of dangers from other drivers. It's just the mechanical failures that I dread then.
I loved riding my motorbike when I had it. Alas I'm sorry to say I can't see me getting back on one anytime soon. The risks, in all motoring environments, are just too high. Especially when doing it daily on a commute.
Good luck to all those bikers who do manage to stay with it. Ride safe!
Living in Chelmsford (Essex) and now working in Oxford Circus (Central London) I've opted to introduce 8 miles of walking in to my working day. The biggest walk being the 45 minutes between Liverpool Street Station and Oxford Street. With a train in the middle. And a walk from home to Chelmsford Station to boot. It takes quite a while. How long it will last I do not know.
A simpler alternative would be to get back on a motorbike. A rattle down the A12 and then battling the urban streets.
The problem is that I recently sold my motorbike after coming off last year in London when commuting to one of my client sites. I had done the journey many times and had become somewhat used to it. Someone pulled out in front of me from behind a station vehicle in queueing traffic and I was knocked off at less than 15 miles an hour. Still managed to dislocate my shoulder and fracture my humerus in four places though!
I had been motorcycling for two years by that point so was certainly comfortable with my machine (a Honda TransAlp XL650V for those who are interested).
The problem is that as soon as you take a motorbike in to a busy urban environment full of commuters you raise the level of risk enormously. To fully take advantage of your mode of transport you need to duck, dive, filter, overtake and generally 'zip' about. It is possible to do all of this safely as long as you concentrate on what you're doing and look / plan ahead.
What you cannot plan for is what the other vehicles, cyclists and pedestrians do around you. My accident happened because the van driver I was filtering past had flashed the driver who knocked in to me to tell them to pull out of a junction in front of him. What he had not done is check in his mirrors for motorcycles or other overtaking vehicles. As it transpired the lady who hit me had only recently passed her test (3 months I think she said) and so had assumed all would be clear and had literally spurted out in front of me. I remember grabbing a handful of brake (no ABS), feeling the back wheel lock, the bike swerve and then reaching my arms out in front of me to try and stop the pavement looming. There was no damage to her car or anybody else at all. Just me and my bike.
I get really annoyed now when I see scooter and motorcycle riders with inadequate clothing or footwear. I had the proper gear on and still managed to injure myself pretty badly.
Some might say that you can ride a motorbike without filtering and then you will be perfectly safe. I disagree. In fact I hear quite a lot of stories of motorcyclists who have braked to a stop but had the vehicle following them not stop in time and thus crash in to the back of them. Potentially fatal.
And I've not even looked at the danger of riding a motorbike at speed on a fast A road or motorway. If an engine ceases or a tyre blows at that speed I dread to think of what the consequences can be. I generally feel riding on these fast roads feels safer in terms of dangers from other drivers. It's just the mechanical failures that I dread then.
I loved riding my motorbike when I had it. Alas I'm sorry to say I can't see me getting back on one anytime soon. The risks, in all motoring environments, are just too high. Especially when doing it daily on a commute.
Good luck to all those bikers who do manage to stay with it. Ride safe!
Wednesday, 1 September 2010
Major Sage 50 Accounts 2010 #fail
This morning I opened up Sage (as you do) to be presented with the following message:
Clicked No and the software just terminated.
Clicked Yes and it then made a great show of looking for updates and then showed me this message:
Click on Close and the software just terminates. Game over. Do not pass Go. etc.., etc..
Not impressed.
I didn't even bother phoning Sage for support. Instead I contacted my accountants. The last time I had opened Sage (a week or so ago) I had just restored a backup file they had sent me after processing my company quarterly VAT return. I had then made changes to that file. And Sage had appeared to be happy. Even backing up as usual, etc..
To quote from the very prompt response from my accountants:
Don’t panic we have recently found out that sage isn’t automatically updating on 1 particular update. We had to manually update our version and you will have to do the same to be able to use my backup.
They were indeed correct. Once I had manually downloaded and installed 'Update 2' (dated 26th March 2010!) Sage loaded properly and I was able to continue with my work.
I am astonished that a company as large as Sage can break their own automatic updates system to such an extent that a user is presented with dead software like this when least expected. At no point have Sage ever communicated the need to manually update the software in this manner. And I'm a fully paid up, licensed customer.
Not likely I'll be upgrading to '2011' anytime soon chaps. How about sorting out your current codebase before you start trying to push new versions on your customers!
Monday, 16 August 2010
Java unsigned int to signed byte and back again
In the last month or so I've been spending a lot of time playing with protocols in Java. Having previously done this kind of work in either .NET or C++ I had become accustomed to having unsigned data types available to me. So coming to Java I was a little shocked that they were missing. This seems somewhat accepted in the Java community so I am, of course, going with the flow.
Despite Java having some very useful classes like the java.io ByteArrayInputStream and ByteArrayOutputStream I found very little information out there on what exactly happens when you want to read or write unsigned byte values. So I wrote a little bit of test code to prove that my understanding was correct:
int in, out;
byte b;
in = 0;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 127;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 128;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 255;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
Which produces the following output to the Console:
in=0, b=0, out=0
in=127, b=127, out=127
in=128, b=-128, out=128
in=255, b=-1, out=255
Hopefully this might be of use to somebody. It certainly made me feel more at ease 'flinging them bytes about'!
Despite Java having some very useful classes like the java.io ByteArrayInputStream and ByteArrayOutputStream I found very little information out there on what exactly happens when you want to read or write unsigned byte values. So I wrote a little bit of test code to prove that my understanding was correct:
int in, out;
byte b;
in = 0;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 127;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 128;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
in = 255;
b = (byte)in;
out = b & 0xff;
System.out.println("in=" + in + ", b=" + b + ", out=" + out);
Which produces the following output to the Console:
in=0, b=0, out=0
in=127, b=127, out=127
in=128, b=-128, out=128
in=255, b=-1, out=255
Hopefully this might be of use to somebody. It certainly made me feel more at ease 'flinging them bytes about'!
Java String valueOf and StringBuilder append - int and char differences
I'm in the middle of writing some code which uses the InputStream read function. InputStream.read() returns a value of -1 when you get to the end of the stream but until that point it returns a byte (0 to 255).
I am pushing these bytes to a StringBuilder and wanted them to be interpreted as their ASCII character codes. What's not obvious from the documentation is that char is treated very differently from other numbers pushed to a StringBuilder with the append function.
The documentation for StringBuilder append(char) states: Appends the string representation of the specified char value. The char value is converted to a string according to the rule defined by valueOf(char).
The documentation for StringBuilder append(int) states: Appends the string representation of the specified int value. The int value is converted to a string according to the rule defined by valueOf(int).
Identical definitions!
The documentation for String valueOf(char) states: Converts the specified character to its string representation. Returns the character converted to a string.
The documentation for String valueOf(int) states: Converts the specified integer to its string representation. Returns the integer converted to a string.
Again, identical definitions. But...
This test code:
int a = 65;
int b = 66;
StringBuilder sb = new java.lang.StringBuilder();
sb.append("int a = [");
sb.append(a);
sb.append("], char a = [");
sb.append((char)a);
sb.append("], int b = [");
sb.append(b);
sb.append("], char b = [");
sb.append((char)b);
sb.append("]");
System.out.println(sb.toString());
Produces this console output:
int a = [65], char a = [A], int b = [66], char b = [B]
As tested against the Java SE 6 SDK.
Which confirms that StringBuilder append and String valueOf behave differently for int and char types. For my particular requirements here this is the behaviour I wanted - and logical enough to cast an int to char to get this behaviour. But to someone who might be coming from a different programming environment (say, for example, one with unsigned data types!) then this might not be so obvious - hence why I've posted this article!
I am pushing these bytes to a StringBuilder and wanted them to be interpreted as their ASCII character codes. What's not obvious from the documentation is that char is treated very differently from other numbers pushed to a StringBuilder with the append function.
The documentation for StringBuilder append(char) states: Appends the string representation of the specified char value. The char value is converted to a string according to the rule defined by valueOf(char).
The documentation for StringBuilder append(int) states: Appends the string representation of the specified int value. The int value is converted to a string according to the rule defined by valueOf(int).
Identical definitions!
The documentation for String valueOf(char) states: Converts the specified character to its string representation. Returns the character converted to a string.
The documentation for String valueOf(int) states: Converts the specified integer to its string representation. Returns the integer converted to a string.
Again, identical definitions. But...
This test code:
int a = 65;
int b = 66;
StringBuilder sb = new java.lang.StringBuilder();
sb.append("int a = [");
sb.append(a);
sb.append("], char a = [");
sb.append((char)a);
sb.append("], int b = [");
sb.append(b);
sb.append("], char b = [");
sb.append((char)b);
sb.append("]");
System.out.println(sb.toString());
Produces this console output:
int a = [65], char a = [A], int b = [66], char b = [B]
As tested against the Java SE 6 SDK.
Which confirms that StringBuilder append and String valueOf behave differently for int and char types. For my particular requirements here this is the behaviour I wanted - and logical enough to cast an int to char to get this behaviour. But to someone who might be coming from a different programming environment (say, for example, one with unsigned data types!) then this might not be so obvious - hence why I've posted this article!
Saturday, 24 July 2010
Changes to Google's Android Market Developer Distribution Agreement (DDA)
This morning I had a new message from 'Android Market' in my inbox. It stated:
You are receiving this email because you have applications published in Android Market.
We'd like to let you know that there is a new Developer Distribution Agreement (DDA) for Android Market. The next time you sign in to the Android Market publisher website, you'll be asked to agree to these new terms before continuing. If you have not accepted the new DDA by Monday, August 23, 2010 12:00:00 PM Pacific Daylight Time, your application(s) will be unpublished from the Android Market.
You can view and accept the new agreement by visiting http://market.android.com/publish/ddaUpdate. Please do not reply to this message.
Thanks,
The Android Market Team
As I've only recently become an Android developer I sat up and took notice. Maybe more experienced developers get this kind of e-mail every month or so and are just used to agreeing to the new agreement without looking at the changes that were made. I had made the point of printing out my original DDA so took the time this morning to compare the original (retrieved from Google's UK DDA publishing point on 24th June 2010).
So, what did I find?...
Section 3.2: The URI specified for 'Transaction Fee' used to be http://market.android.com/support/bin/answer.py?answer=112622 which works. The new document states a new URI as http://www.android.com/support/market/bin/answer.py?answer=112622 which does not work - or, at least, has not worked for the last three hours (between 6am and 9am GMT, 24 July 2010). This is what I get:
Hmmm... Maybe it's on the TODO list of somebody at Google for Monday morning?
Section 13.1: I don't have any legal qualifications of any sort but this is the first paragraph where there is a significant change. It talks about indemnification. They've juggled the stakeholders around a bit but from what I can see the main implication is that they've now added 'any Authorized Carrier' as an additional entity that we, the developers, need to be protecting from law suits!
Section 13.2: Brand new paragraph. How exciting! Looks like an attempt to protect Google and (more importantly) the payment processor (err, that'll be Google again then!) against tax authorities. That is we, the developers, indemnify them against claims in that respect too!
It's worth noting that the agreements I've been reading are specific to the UK and that Google do publish different documents for other jurisdictions (e.g. US and Australia).
I'm not sure how often Google update the DDA but the strict tone of the alert email makes me wonder if there's an ulterior motive here. Is this a handy way of 'booting' the various Spam developers who flood the Market. I wonder.
And, finally, if I'm going to get really picky...
Section 7.2 (c): Typo in both documents 'rgeulations' should be 'regulations'.
Section 15.1: Typo in both documents 'acse' should be 'case'.
But then in my limited exposure to the legal fraternity (getting contracts drafted for my business in respect of employment law) I've never been very impressed with their accuracy or ability to work the basic tools of the trade... like, for example, a word processor!
You are receiving this email because you have applications published in Android Market.
We'd like to let you know that there is a new Developer Distribution Agreement (DDA) for Android Market. The next time you sign in to the Android Market publisher website, you'll be asked to agree to these new terms before continuing. If you have not accepted the new DDA by Monday, August 23, 2010 12:00:00 PM Pacific Daylight Time, your application(s) will be unpublished from the Android Market.
You can view and accept the new agreement by visiting http://market.android.com/publish/ddaUpdate. Please do not reply to this message.
Thanks,
The Android Market Team
As I've only recently become an Android developer I sat up and took notice. Maybe more experienced developers get this kind of e-mail every month or so and are just used to agreeing to the new agreement without looking at the changes that were made. I had made the point of printing out my original DDA so took the time this morning to compare the original (retrieved from Google's UK DDA publishing point on 24th June 2010).
So, what did I find?...
Section 3.2: The URI specified for 'Transaction Fee' used to be http://market.android.com/support/bin/answer.py?answer=112622 which works. The new document states a new URI as http://www.android.com/support/market/bin/answer.py?answer=112622 which does not work - or, at least, has not worked for the last three hours (between 6am and 9am GMT, 24 July 2010). This is what I get:
Hmmm... Maybe it's on the TODO list of somebody at Google for Monday morning?
Section 13.1: I don't have any legal qualifications of any sort but this is the first paragraph where there is a significant change. It talks about indemnification. They've juggled the stakeholders around a bit but from what I can see the main implication is that they've now added 'any Authorized Carrier' as an additional entity that we, the developers, need to be protecting from law suits!
Section 13.2: Brand new paragraph. How exciting! Looks like an attempt to protect Google and (more importantly) the payment processor (err, that'll be Google again then!) against tax authorities. That is we, the developers, indemnify them against claims in that respect too!
It's worth noting that the agreements I've been reading are specific to the UK and that Google do publish different documents for other jurisdictions (e.g. US and Australia).
I'm not sure how often Google update the DDA but the strict tone of the alert email makes me wonder if there's an ulterior motive here. Is this a handy way of 'booting' the various Spam developers who flood the Market. I wonder.
And, finally, if I'm going to get really picky...
Section 7.2 (c): Typo in both documents 'rgeulations' should be 'regulations'.
Section 15.1: Typo in both documents 'acse' should be 'case'.
But then in my limited exposure to the legal fraternity (getting contracts drafted for my business in respect of employment law) I've never been very impressed with their accuracy or ability to work the basic tools of the trade... like, for example, a word processor!
Subscribe to:
Posts (Atom)