Thursday, 11 June 2015

I had ported a project from Eclipse to Android Studio and one of the things I needed was an assets folder. I keep encryption keys in it but there is no assets folder by default in Android Studio.

Solution: Right-click the module (e.g. app) and choose New > Folder > Assets Folder and it will put it into your project and into the correct place on the file system. If you want to find that place, right-click the folder after creation and choose "Show in Explorer" or whatever it says on other platforms.

As you have probably worked out, in Android Studio, if you want to add an existing item, you can just copy it into the relevant directory and Android Studio will pick it up automatically into the project.

But not always. For some reason.

To work around when it doesn't happen, I just hit Build -> Clean Project and it seemed to re-sync. I couldn't seem to force it any other way but hey.....

I don't write loads of Android code and it has been about 6 months since I last did anything in anger but I once again ran up Android Studio (HIGHLY recommended for Android development) and set about creating a new demo app to use with our PixelPin mobile app. I will write a few specific posts about things that I have seen.

The most major was trying to use the app to call into an Activity I had added to the project. The debugger wouldn't report anything, the app just died when calling startActivityForResult.

The problem? Not adding the activity into the application manifest! I just about caught the error in the logcat output but sadly, my Samsung S4 mini spits out about 10 errors a second! from all manner of services and apps, something that is very poor in my opinion since logging is recommended to be switched off in production, partly for security and partly for usability.

Wednesday, 10 June 2015

I kept getting this error from a newly deployed .Net web service when trying to access the SVC file.

The web services works, which is unusual but it was just the svc file and therefore the wsdl that wasn't. However, I could use svcutil to create the client classes so that was also weird.

tl;dr? I use a client certificate for authentication. If this is set to negotiatessl instead of requiressl in the web configuration, Firefox WON'T ask you to choose a client certificate. Instead, you get a 403 (forbidden) error returned with no body and Firefox in it's wisdom decides that because it asked for xml, the response must also be xml but blank is obviously invalid and you get the error.

When I ran Fiddler to check the request/response, it all worked correctly (obviously Fiddler found the correct CC and used it!) but when you use Chrome, it was clever enough to work it out and ask you to choose a client certificate. Whether this was because of a previous call which cached the client certificate need or by some other means, I don't know.

So you can't test this on FireFox it seems (without using Fiddler) but would need to use Chrome instead. Naughty Firefox.

Thursday, 4 June 2015

Let's be honest, it sounds easy. Write a few lines of PHP or knock-up some wordpress with a theme, tinker around with it and sell the service to your customers for a few thousand dollars a pop. I've made a wordpress site in less than an hour so even with some customisation, I should comfortably finish in week so a few thousand dollars for that is good right?

It would be great, except.....

It doesn't work like that for a whole load of reasons. These not reasons that you learn on one of those "learn to code in 30 days" courses that promise so much. All they really teach you is a few basics but learning to lay bricks does not enable you to build a house, there are a load of other issues. Most of these come out in testing obscure combinations of things late in the day when you thought you were nearly finished and which although you don't think are very serious, the customer thinks they need to be fixed before they can possibly sign-off the site.

There is also the difference between your assumption: That the customer knows exactly what they want before you start anything and the reality: The customer has no idea about anything, including their own business processes and they definitely have no expertise in anything web related so usually what happens is that you think you have a whole lump of the site finished before the customer then decides, "now that I can see it, I've realised that it won't work properly".

There are soooooo many examples of this happening in all sorts of trades but I see most of it in web designs and the massive gap between customer expectations and your own expectations.

So where do we need to rewind to? The first contact:

Customer: How much for a web site?
You (should say): There is no way on earth I can answer that question without knowing almost everything about your system
You (actually say): They usually cost around $2000 depending on how complex
The customer hears: It will cost $2000 unless some kind of natural disaster occurs.

Straight away, your expectations are already adrift because you want to be nice and helpful (engineers like being helpful) but you are not being helpful because you are creating a poor foundation. It would be great if developers could start acting like professionals. Could you imagine saying to an architect, "how much to design a house"? What would the architect say? So why don't we say that?

We should have a pre-packaged piece of text that describes what affects the price of a web site. We can point people to it on a web site or we could print it out and give it to them. Let them know that although web sites look simple, they are not. Small changes on the surface can have large knock-on effects in timescales, stability and most importantly: costs!

This is hard because some people will say, "a web site costs X dollars" and the customer thinks you are being awkward and evasive so they go somewhere else but you already know that people say that, so you need to manage it, you need to tell people convincingly that anyone who offers a fixed price is either going to short change them or will not allow them to make changes.

So knowing that customers do not usually understand web technologies and sometimes don't even understand the business they are trying to help with their new web site, you have to manage that too. You should really employ a Business Analyst who is both cheaper than an equivalent developer but also, hopefully, much more skilled at digging into what the business is trying to do. This might be a quick conversation, "I want an online shop" or it might be very complex and take several weeks of time (or longer). The good thing here is that even if they get to that point and things start getting complicated, they can still pay you for your analyst time and could walk away with something that they can reuse later perhaps after saving more money or perhaps once they've thought about what they want.

The really important thing that follows is change control. In smaller companies, we get a call from the customer and he says, "I just noticed that button was a bit small, can we change it?". Of course we can, we are helpful but what is the knock-on effect? How are we going to record or charge them for this work? Seems small but we still need to pre-empt what will really happen. The customer will ask for loads of small things without realising how quickly they add up, they will then be surprised at the bill we are sending them and get all funny thinking we are ripping them off. It's a pain but we need to manage change - it does happen. We might have included some hours in the bill for rework, which we will agree up-front. All changes are then requested, put into some technical detail and costed and then SENT BACK to the customer to authorise. Funnily enough, the person paying the bill is usually tighter than the people who are asking for the changes so let them argue about whether the change is important now or never! The same list gets added to for every change, the billing amount increases each time so the customer has visibility. We should do NOTHING until it has been authorised however tempting it is because then we are working for free and you will eat up enough of your free time fixing unexpected things.

So then how do we finish? If they keep paying you to change things and are happy to defer the release of the site, that's their call but you have to decide before you start the project what your acceptance criteria are. At what point can you objectively say that you've finished? Again, you know that people have different opinions on things so work it out in advance, put it in a document and get it agreed. You might say that the site will work functionally on all the latest versions of browsers and IE from version 8 onwards (for example) meaning that the site is navigable and looks close to correct. You might exclude browser-specific layout issues that are minor and you might exclude any browsers that are not mainstream. If it's broken in them, it's up to the customer to pay to fix it if they think it's important enough, otherwise, it doesn't get done.

Of course, the job doesn't stop there. You have a working site and 2 days later, someone calls you up again and says that X,Y,Z isn't working. Perhaps the server disk is full, perhaps the database has fallen over but have you agreed up-front what service you are providing? You might say that you will investigate and find problems for free but fixing them will cost money except in certain cases where you have made some kind of serious error. Of course, the customer will want you to support it forever but that is probably not your main job so make sure you charge money for it (most industries give X months free cover and then you're on your own or you pay) and MAKE SURE you have agreed this all up-front so you can point to the document and say that replacing broken hard disks is not included in the price and you will charge X hours at Y dollars per hour.

This stuff seems boring but it will totally increase your profitability. It's not that the current popular way of working is providing cheap sites for people, it is providing inefficient expensive sites that are a pain for the customers who order them and a pain to the developers who are building them!

Learn these things, ponder them, consider the types of things that will go wrong and then put in place some kind of framework that makes it pleasant for the customer and efficient for you!

This error has probably been seen by most .Net developers at some point and the solutions seem to be easy but yet they weren't working on my latest site, which was showing this error only on mobiles!

ViewState is a way of storing control data in the page so that the server doesn't need to store everything for every single session. You can also store your own values in it, such as CSRF tokens and whatever else you want.

These are all in a hidden form field and are signed by the server using (usually) HMACSHA1 or in .Net 4 HMACSHA2(56) and get posted back to the server. The server then uses its machine key to verify the value that has been posted still matches the signature. If not, it assumes someone has tinkered with the value of ViewState and shows the above error in all its glory!

So when does it fail validation without it being an error?When the machine has recycled/rebooted and has re-generated its machine key, the signature process will obviously produce different values and will look wrong.

It can also happen in a web server farm since each web server will produce its own machine key and a request being posted back to a different server will fail validation. This is usually fairly consistent unless you are expecting sticky sessions where the same session gets linked to a single server but for some reason that hasn't happened.

The problem in my case was that I have a single server and even when I recycled the app pool for the server, it never seemed to fail from the desktop so I assumed that the machine key was safe. In fact from IIS 7.5, the machine key is supposed to be written to a special area that is accessible by all users to avoid a previous permission problem when an app pool tried to write keys to the registry.

Well, whatever was happening, the problem is that Chrome mobile is caching so heavily that even when it looks like it's refereshing, it isn't refreshing (even entering the address bar and pressing Enter or loading it on another tab). It resubmits the same stale page with the old viewstate and it fails validation. The only way I managed to force the reload was to redirect all http to https on the server (something I was going to do anyway) and then it seemed to reload OK.

Fortunately, the solution is pretty easy in all cases - hard-code a key into the web config and so the site always uses the same signing key.This uses the machineKey element under system.web and you can generate a key here.

Once that has done, it should hopefully stop all instances of this occuring across deployments, but I am going to add a fairly short cache duration on the main page just to try and give it some extra help!

Followers

About Me

I work for PixelPin being in charge of all development for our company, which includes mostly .Net web applications but also PHP, Android and iOS programming as well as managing our hardware and cloud-based systems.

I live in Cheltenham, Gloucestershire in the UK which is lovely in the summer and miserable in the winter.