Topic: WinRT / Windows 8 Client Development (Read 1733 times)

I am still undecided on WinRT. At first glance it seems to be very limited, but I think that could be a result of lack of documentation.

For instance I implement the SocketStream class to send/receive bytes over tcp. While first looking into it many forums said that 2 way communication was not possible, and it only allowed you to send bytes once connected. The recommended solution was to use websockets. Of course in actual implementation I was able to use the SocketStream to easily perform 2 way asynchronous communication. This wasn't the first incident of bad information out there, and the more I research it the more I realize many people have their facts wrong when giving information on WinRT. So for me the jury isn't out yet, I will know more as development progresses.

Microsoft is still to blame either way. They need more in depth tutorials for advanced programmers.

On the plus side, I am a huge fan of the Metro Style interface especially on Tablets/Phones. As for desktops I have mixed feelings about it.

I gave up on this winrt system for bitcoin a while ago... winrt seems, to me, pretty limited when it comes to implementing what is needed for bitcoin.. although i followed the approach of creating a metro wrapper for bitcoin instead of recreating the whole thing..

No, it doesn't sync the entire block chain. It uses Bloom filtering and getheaders to only sync the headers plus the relevant transactions. It's quite light enough even for cheap data plans.

I was actually discussing this with someone at work today. Still somewhat unclear how this was actually handled. Has the fork resolved itself? It appears that the initial recommendation was to revert to 0.7, but then later it was decided to push on to 0.8 instead.

Looks like there needs to be a slower and more controlled rollout process. I still don't know all the details, but it seems strange that two nodes would be allowed to talk to each other using different protocols.

Dealing with forks is a good example of some of the complexity in the Bitcoin protocol.
Have a look at this test for an idea:
http://code.google.com/p/bitcoinj/source/browse/core/src/test/java/com/google/bitcoin/core/ChainSplitTest.java

The recent hard fork v0.7/ v0.8 is a good example of this happening in real life but it happens fairly often at the 1 or 2 block fork level.

It may be better to write a new gui that replaces the bitcoin-QT client.

Since Windows 8 (and windows phone supports C++ now. 

Very nice, I will look through the project later I am sure it will be of value. Does it sync the entire block chain dataset? How does this affect data plans on the users phone?


Getting it into the Windows Store is likely going to be a bit more of challenge then a copy and paste. In WinRT when you navigate away from an app it suspends all processing. Only one App can be active at a time. That being said it appears there are methods to keep certain types of background processes going, so that will be the next learning curve. It's obvious Microsoft would prefer backgroung tasks be avoided as much as possible. However we can't expect a user to sit at the app screen for hours while it syncs the blockchains.

I also built my own network access layer code generator. In past projects I would build up my protocol specification within this app, and it would output the server code in .Net, and output the client code for both .Net/Silverlight. All send functions and receive handlers become exposed through an interface. The benefit with this approach is all serializion/deserialization takes place in a consistent manner and as far as the consuming developer is concerned they are just strongly typed classes with no knowledge of the networking. I went this route because I am accustomed to WCF development and I wanted to simplify my own development. Of course Bitcoin slightly breaks my model since messages are wrapped differently, combined with the learning curve of adopting WinRT. So there are some roadblocks for sure since my code generator does not support WinRT.

More than anything else I actually want to have a better understanding of how it works, and I get to learn WinRT at the same time. The hands on approach has helped me in the past. There is a good possibility your libraries will remain superior to mine, but my objective isn't necessarily to compete with anything. After all I intend to release it for free.


If you wouldn't mind, could you elaborate on some the more difficult/tricky problems you encountered? I'm still interested to see if you can talk me out of it

I would strongly advise you to check out the code for bitcoinj before you go any further:

http://code.google.com/p/bitcoinj

In particular, I'd advise you to consider either using the Java code directly via IKVM or using an automated Java to C# converter. Implementing the "business logic" on top of network serialization is a LOT of very tricky work, especially if you want good performance on smartphones. BitcoinJ is already designed for smartphones and has lots of optimizations that are useful for that. It'd be a shame for you to try and reimplement it all. It's been 2+ years since I first wrote my first network deserialization code and we're still going, still optimising and making the code work well on all kinds of phones. So unless you're OK with signing up to a multi-year effort, consider code re-use.

Hi Everyone,

I am building a Windows 8(WinRT) bitcoin wallet, I will use this thread to provide status updates or to assist others with their own implementations.

Before I get too far along in my development I will outline my current approach so that forum members can offer some criticisms if I seem to be going in a wrong direction.

The solution contains the following projects

1. BitcoinSchemas

This is a .Net Portable Class library, meaning it can be added and compiled against many frameworks such as Silverlight, .Net, and WinRT. It contains a set of serializable classes so that in future I may serialize them into XML/JSON should I choose. However currently I am only working with sockets so these classes end up being processed by my own packet readers/writers.  

This project contains no logic, only types.

2. BitcoinPortable

This is again a Portable Class Library. It contain logic pertaining to Bitcoin that does not require any framework specific namespaces. So in future I may create a .Net or Windows Phone client without duplicating logic.

3. Helpers

Generic helpers not specific to bitcoin such as converting Windows DateTime to Unix Time.

4. BitcoinWinRTNode

This is a Windows Store Class library and contains all functions required for communications with other nodes. I am trying to make sure it is abstracted as much as possible so that any developers new to bitcoin can quickly jump in and follow the logic. I should be able to support new command types in the future without modifying any of the low level networking. Also includes lots of comments.

Majority of logic in here is wrapped in asynchronous/non blocking code. It should never cause a deadlock within referencing UIs.

5. BitcoinWinRTWallet

This is a Windows Store App that I am building, it references the WinRTNode library for communicating with the rest of the bitcoin network. I use the MVVM design pattern by using asynchronous relay commands, and binding UI elements to viewmodel properties.



Current Status

All of these libraries have been created and in the beginning stages of development. I've got my networking API finished and seemingly bug free. In my implementation I have all message commands wired up to event handlers, however most of them aren't performing any business logic yet. Most are just skeleton handlers at the moment that receive the payloads.

These empty handlers basically look like this:

Essentially everything runs asynchronously, I am currently not manually creating threads anywhere. I leave it to the runtimes task scheduler. In terms of the UI I've got a few screens built, I've also created my own brand identity(ProductName/Logo/Color Palette). Although the brand details could still change at some point. I don't plan on releasing too many details right now, unless of course someone else in the forums requires assistance with their own app. I will post code snippets as needed until I am ready to go open source.



Now I do have some dumb questions.

1. If all of the nodes connect via sockets, then what purpose does the RPC-JSON serve?
2. I've built JSON Web Services many times, but how would this differ from the RPC-JSON approach? As far as I would be concerned calling a web service method is a remote procedure call. However I've read some contradicting information in the forums.
3. I'd like to release all my code to be open source at some point. However I do not want to restrict myself or anyone else from using these libraries for commercial purposes should they choose. I don't work in open source projects often. What is the best licensing model I should use for this?
 
I would be willing to build a WCF web module for the JSON component should anyone request it.

Thanks