В этом релизе были добавлены следующие возможности:

• Модели типа Expando: Объекты теперь могут содержать свойства с списком, состоящим из различных типов данных
• В интерфейс Memcache API были добавлены функции add_multi и replace_mult

Также были устранены следующие ошибки:

• Некорректная работа класса StringListProperty
  
• Поле типа TimeProperty теперь может содержать значение datetime.time(0,0)

Также тихо и незаметно прошел выпуск SDK версии 1.1.4 SDK в пятницу 26 сентября, который исправил два важных бага под Windows: один из них проблемы со значениями параметров в файле app.yaml, а другой - некорректная работа вьювера хранилища в SDK.

Мы всегда рады видеть вас в группе Google!

The main header is "WebCore.h", so include that to access the entirety of the API. Almost everything is documented using standard Javadoc commenting and so it should be pretty easy to understand (I'll probably generate online docs later using Doxygen). If you need any tips on usage or an idea of how to embed Awesomium within your application, take a look at the 'app' project in the SVN source.

Good luck and have fun!

P.S., remember to copy over the ICU DLL (it's in bin/common) into your executable's directory as well. If you don't, everything will probably still run however various operations (mostly text-input and unicode-related stuff) will most definitely fail, causing undefined behavior.

P.P.S., I've started a discussion group to discuss development/support of Awesomium, check it out here!

JUHUUU!!!!!!!

Nach dieser Meinungsäußerung meinerseits hier kurz alle Fakten des Briefes zusammengefasst:

1. Das Aufheben gilt nur für bereits veröffentlichte Software. Zukünftige Planungen Apples/der Entwickler müssen weiterhin gehemigehalten werden.
2. Apple hat eingesehen, dass diese Vereinbarung schlecht für Entwicklergemeinschaften und SDK-Buchautoren gewesen wäre.
3. Eine abänderte Fassung des Vertrages ohne die Einbeziehung von veröffentlichten Apps wird vorraussichtlich in einer Woche erscheinen
4. Fucking NDA hat geholfen!!!

I'm working on an iPhone application at the moment. I'm learning as I go, so progress is quite slow. Recently I've been trying to work out how to dismiss the on-screen keyboard when the user has finished editing the contents of a text box. Due in part to the (Now lifted) Non-Disclosure Agreement that Apple was forcing people to accept if they wanted to develop for the iPhone, there's not a lot of information out there on iPhone development.

In any case, I recently stumbled across the answer here, which seems to work quite nicely. I've run up a quick sample to illustrate it, as much for my own benefit the next time I need to do it as for anything else.

Essentially, you need to do a few things:

1. The Controller of the View that contains the text field(s) you're interested in needs to implement the UITextFieldDelegate protocol.
2. The text fields themselves need to have their delegate set to the View Controller.
3. You need to implement a function that will be called every time the user hits return in a text field that's within your View.

To satisfy point 1, your View Controller's .h file needs to contain something like this:

@interface MyViewController : UIViewController <UITextFieldDelegate> {


For point 2, it's a case of firing up Interface Builder and, for each of the text fields you're interested in, dragging the "delegate" connector onto the "File's Owner". When you've got it right, the connector tab for the text field will look like this:

For point 3, you need to implement the function below with your View Controller's .m file:


- (BOOL)textFieldShouldReturn:(UITextField *)theTextField {
[theTextField resignFirstResponder];
return YES;
}


...and that should do you.

Common Language Runtime Support

For the sake of this discussion, I’m going to assume some familiarity with the Common Language Runtime (CLR) and .NET development, but will dive into some of the details regarding its support for 32-bit and 64-bit applications. The 2.0 release of the CLR introduced a 64-bit version in addition to the already existing 32-bit version. Along with this, the capability to have your .NET code compiled to target a specific platform was also introduced. For instance, when developing with C# and Visual Basic, the developer can pass in the /platform switch to the compiler with potential values of x86, Itanium, x64, or anycpu with anycpu being the default if the switch is not provided. As you can see, this allows the developer to control exactly what platforms the compiled .NET code can execute on. For executables, what happens is relatively straightforward – x86 compiled executables run in 32-bit mode on all systems (WOW64 on 64-bit operating systems), x64 will only execute on computers that support the AMD64 or EM64T instruction sets, and for executables compiled with anycpu, the application will run as a 64-bit process on 64-bit operating systems and a 32-bit process on 32-bit operating systems. Similarly, .NET class libraries can be loaded by an executable only if they support the platform that the loading executable is running under. Therefore, a 32-bit process cannot load a .NET class library that is compiled as x64 assembly only and a 64-bit process cannot load an assembly that is compiled to be x86 only. However, if the class library is compiled as anycpu, it can be loaded by both 32-bit and 64-bit processes.

You can refer to the articles referenced at the end of this article for more information regarding how to build 64-bit applications using the CLR and the .NET Framework.

CRM 4.0 SDK Assemblies

To determine what platform a specific assembly is compiled to target, you can use the CorFlags.exe tool included with the .NET SDK. Simply running it with the file that you want to examine as a command line argument, you will be able to gather enough information to determine what platforms the targeted file supports. For instance, here’s what the output looks like when running CorFlags.exe on the 32-bit version of Microsoft.Crm.SdkTypeProxy.dll.

The important pieces of information here are the PE and 32BIT values. The breakdown for the various different platform targets and their associated values are as follows:

Based on this chart, we can see that this is indeed the 32-bit version of the Microsoft.Crm.SdkTypeProxy assembly. If we ran the same command on the 64-bit version, we’d see that it is compiled with the anycpu value. I won’t get into the details about why these are compiled as such, but given this information, we can start seeing where the problems might pop up during solution development and when it is appropriate to use the two different sets of CRM 4.0 SDK assemblies.

For more information regarding CorFlags.exe, refer to the link at the end of this post.

CRM 4.0 Solution Development

Now that we have understand of some of the details about how the CLR executes .NET code in 32-bit and 64-bit processes and the differences between the two sets of CRM 4.0 SDK assemblies, let’s talk about what it takes to build a portable solution against the CRM 4.0 SDK. There are several different places where you may write code that links against the SDK assemblies, so let’s walk through each of them.

Plug-ins

Plug-ins could be one of the more challenging ones to get correct given the different factors making up who will actually end up executing the code. If the plug-in is registered to execute synchronously, it will execute in the IIS worker process, if the plug-in is registered to execute asynchronously, its execution will be in the MSCRM Asynchronous service, and if the plug-in is available offline, it will run in the Outlook client hosting process. Depending on the complexity of the CRM topology that your plug-in is running in, the “bitness” of the various processes that will execute your plug-in may be incompatible with each other. In this case, the best solution would be to see if you can compile your plug-in code using the anycpu option as this would allow your plug-in to execute in each of these processes without any changes. If you require your plug-in to be compiled platform specific, then you will need to take into account how the plug-in is going to be registered, the processes that may execute the plug-in, and ensure that your plug-in is compiled in a manner that is consistent with the bitness with which those processes will run. This may, however, limit the portability of your solution and require that you have different plug-in assemblies for the different environments you plan on deploying your plug-ins in.

Custom Workflow Activities

Custom workflow activity assemblies pose many of the same challenges as plug-ins. The one scenario we can rule out is having the custom workflow activity executing in the Outlook client hosting process. However, both the IIS worker process and MSCRM Asynchronous service may load the custom workflow activity assembly at various points in a workflow’s lifetime. Therefore, like plug-ins, if you can compile your custom workflow activity assembly with the anycpu option, you can rely on the CLR and CRM to do the heavy lifting for you. If you need to compile your custom workflow activity assembly to be platform specific, you’ll need to ensure that you are registering a version of the assembly that is compatible with the CRM processes that it will execute in for the environments you want it to have it registered.

SDK Client Applications

This type of solution is the one that developers hit most often as the code is not executing from within CRM, but rather an external process that is reading and writing data from CRM via the SDK. When the code is executing within a CRM process, the CRM setup process will ensure that the correct SDK assemblies are in place to ensure that your solution can execute given the CLR restrictions already discussed. However, when calling the SDK from outside of CRM, your application needs to link to the appropriate SDK assemblies so that they can be loaded into your process. Luckily, this is easy to fix using the two sets of assemblies that are now included in the CRM 4.0 SDK. If we look back at the information we gathered from CorFlags.exe earlier, you’ll remember that the 32-bit SDK assemblies are compiled to target x86 and that 64-bit SDK assemblies are compiled to target anycpu. Given this information, simply linking against the 64-bit SDK assemblies from your client application will do the trick as these can be loaded in both 32-bit processes as well as 64-bit processes. If you are building a SDK client application that is going to execute as a 32-bit process only, then you can use either set of the SDK assemblies without running into any issues.

Putting It All Together

As we’ve discussed, there are two sets of CRM 4.0 SDK assemblies – one for 32-bit and one for 64-bit. This may pose problems at runtime for your code, but with a few simple checks and some configuration when building your code, you can make your solution portable across the various environments where your code may execute. The simplest solution is to build your code using the anycpu so that it can target both 32-bit and 64-bit processes and let the CLR and CRM take care of the rest. Luckily enough, this is the default setting in Visual Studio, so you don’t even need to do anything to add this capability to your solution. Just remember to link against the 64-bit version of the SDK assemblies if you are going to potentially run your anycpu code from outside of CRM. If you do need to compile your code to target a specific platform, then you are going to limit the portability of your solution. In this case, you will need to verify that the platform that your code is compiled to target is the same platform that CRM is going to be executing in when tries to execute your code.

To get the CRM SDK assemblies I’ve referred to, you can download the latest version of the SDK.

Additional Resources:

• /platform Compiler Switch
• 64-bit Applications
• Migrating 32-bit Managed Code to 64-bit
• CorFlags.exe documentation

Cheers,

Nirav Shah

If you ever wanted a demonstration of Apple's out-sized power over the Internet chattering classes, you need look no further than the front page of Techmeme, the premier site for catching up on the hottest tech news of the day.

On Wednesday morning, Apple (AAPL) announced on its developers Web site that it was dropping the non-disclosure agreement (NDA) that prevented iPhone programmers from talking about their applications.

By midafternoon, the announcement was the subject of more than three dozen published articles, with headlines ranging from the lyrical ("Ding Dong, the iPhone NDA's dead"), to the joyful ("iPhone NDA dropped, developers rejoice") to the psychoanalytical ("Apple begins to learn from NDA paranoia") -- all gathered by Techmeme's automated news-picking software and neatly arrayed at the very top of its news feed.

The magnitude of the response was matched only by the narrowness of the issue at stake.

Before they were allowed to write programs for the iPhone, developers had to agree not to talk about Apple's software development kit or the work they did with it -- not to the press, not in trade journals, not even among themselves. A few thousand programmers were affected, including some who had contracted to write books that could not, under Apple's strict rules, be published.

Yes, the free flow of information was impeded. Yes, software development progressed more slowly than it might have if programming tips and techniques could have been shared. Yes, the episode contributed to the rancor that characterized Apple's relationship with much of the third-party software community. (see, for example, here)

But did it require that every tech writer with a blog or access to a printing press weigh in on the development?

And was it the most important thing to be writing about on Wednesday, Oct. 1, in the middle of an economic meltdown and a presidential election, with banks failing and a $700 billion bail-out package hanging in the balance?

In the world of high-tech journalism, apparently it was.

And with Adobe now saying they are waiting on Apple to approve the Flash player for the iPhone it will be intersting to see how this all works out. If Apple really is turning down applications to the iTunes App Store because they compete with Apple's offerings then in theory I'd expect them to turn down the Flash player because it competes with Apple offerings, however if they did turn it down there would be a big backlash I think and serious repercussions for Apple's new baby platform's future...can anyone say anti-competitive practices and double standards...

Read more via the link below about the dropping of the NDA.

(Via The Mac Observer.)

Tras alguna incertidumbre así como diversos comunicados pseudo-oficiales en el pasado, parece que sí que vamos a tener Flash en el iPhone y iTouch. Lo que no sabemos es cuando. Paul Betlem, director de ingeniería de Adobe Systems, ha confirmado que Adobe está desarrollando un reproductor de Flash para dichas plataformas. Lo que también es curioso es que, tras esto, ha añadido que la plataforma es cerrada, y que Apple es la que decide cuándo verá la luz. Si Apple da el visto bueno, estará disponible dentro de poco.

A mediados de junio de este año, el presidente de Adobe afirmó que ya contaban con Flash en un emulador de iPhone (que probablemente sería el emulador incluído en el SDK del iPhone). El tema que está frenando la salida del mismo, confirmado por el propio Steve Jobs, es el rendimiento requerido para su ejecución. Incluso Flash Lite, la versión reducida y diseñada para dispositivos móviles, requiere gran cantidad de recursos, así que veremos qué tal se ejecuta en nuestros gadgets de la manzana.

Para ajudar os destemidos, no site HowtoForge tem um tutorial para instalar o sdk no Ubuntu. Nada complicado!

[ ]'s

Again beginning with this post, there is a disclaimair that am not anti-Apple, but firmly believe that their policies should be badly bashed. I have even based Mozilla Corporation for their policies even though being an Open Source Fan.

First begin with the NDA imposed upon the developers developing apps for iPhone. The only word coming to my mouth is WTF! Apple has such a big community of fans and developers, why are the developers treated like a second grade citizen. Now is it a work of a second standard student to remind Apple that sharing codes and idea is always healthy for an development platform? This is equal to reinventing the whole wheel. Fine! Apple wants to keep the platform closed sources and non-free. Done Apple Done! Now please dont force the developers on your whims and fancies. Now what code they make, should belong to the devs and its upto them what to do with that pretty shit of code. This is am attempt to even surpass Microsoft in their suppressive tactics.

The iPhone platform is beautiful, appealing but highly locked in. No-one can duplicate the functionality of the services provided in the phone. My question is why not? Its upto the users to think on it, whether they want a similar functioning application or not. The Android's statement on this is

Android does not differentiate between the phone's core applications and third-party applications. They can all be built to have equal access to a phone's capabilities providing users with a broad spectrum of applications and services. With devices built on the Android Platform, users will be able to fully tailor the phone to their interests.

which is a slap on the face of Apple's policy. No company/individual has any right to determine what application I install on my personal computer or phone. Its truely my choice and am not a slave of anyone to be supressed.

When submitting apps to the app store, some applications come immediately and some take ages to show up. Many developers have expressed anger over it. Is Apple listening? If they dont care of the developers then what the heck is this SDK for? The most valuable asset a development platform can have is developers and a large user base. Apple has no interest to keep the former in high esteem.

Here are a few answers I got recently , from very large and respectable, best of breed companies.

We admit this is a serious bug, we can't tell you when it will be fixed,because our accountants prohibit us from  disclosing  the information to our clients.

Really, I swear to god that's what they said. The damn accountants cannot stop Meryl Lynch and Enron from stealing  billions of dollars.So ,in their spare time, they refuse to let the customers know when their broken product is going to be fixed.

Now I'm really happy that I have an MBA. I can explain the bizarre logic. If they inform the customer of the fix, the customer future orders can not be recognized in the books because maybe the damn developers will miss the schedule. The result - it is better to hide the information from the customer.

I'm soft closing the tickets ,as the customer has not responded for three weeks.

Really? We just did a one hour webex and reproduced all the bugs for you so even Britney Spears in one of her bad days could understand them. Maybe your defunct support system lost our emails again ? How is this soft ?

SDK ? George, I never heard about something called SDK. Is this related to UNIX ?

We opened a ticket to a large vendor whose SDK has an overflow and returns long int instead of short int, or something similar. not only their support didn't know they had an SDK ,they didn't know what SDK stands for.

Please reproduce the server crash in your production environment so we can have better logs.

Enough said.

We don't know how to sign our Java Applet. We are checking with R&D.

For a Java applet whose security certificate is not valid for more than a year.

Please open an RFE (Request For Enhancement ) so we will support multiple tabs in Internet Explorer 7.

One and half years after IE7 was released and few months before IE8 is about to hit the market.

In many of the cases the problem is not within support, but it actually comes from the CEO. It seems that the market leaders are willing to invest in quality just EKO ( Epsilon-Kra-Oz ) dollars above the level required to keep customers from changing the supplier. Since they are the market leaders and change is extremely hard for Enterprise Software the value of EKO is pretty small. It is about the same as Paul Young's latest record.

In many cases I wondered "Is This It? Is this the best ,Three Letter Acronym Goes here, product in the market "? "It is so slow, and awkward and has so many bugs".

The answer lies in the EKO Constant and that's why a new start-up has a shot. At least until it hires top tier accountants  :)

What is Crystal Reports Embedded? Crystal Reports embedded is an architecture which allows the Crystal Reports Rendering engine to run within the confides of the application environment.  BusinessObjects provides a .NET runtime and a Java Report Component (JRC) which allows developers to embed Crystal Reports in their applications.  Crystal Reports Embedded is included free with every version of Crystal Reports we sell.

So why do I need Crystal Reports Server or BusinessObjects Enterprise?  Well, that leads me into a discussion of the limitations that existing within the "free" embedded report architecture.

Limitations of Embedded Reporting

The current Crystal Reports Embedded Runtime is limited to three concurrent user requests (e.g. three simultaneous processing threads).  These threads are queued such that if the .NET application requests a 4th thread, it must wait until one of the existing three completes before it will be processed by the embedded engine.

Here is a quick view of the Embedded Architecture:

In case you were not aware of this limitation, let me point you do an excerpt I found on the Crystal Reports Developer website:

• Report engine is embedded.

  In Crystal Reports for Visual Studio, the report engine is embedded in the application.

  This embedded report engine is limited to a maximum of three simultaneous user requests. This is not an arbitrary licensing limit; it is a limitation of the embedded report engine architecture.
• Report engine is extracted into a separate report server process

  In the solution that uses the unmanaged Report Application Server (RAS), the report engine is extracted into a separate server process. That server process can run on the same machine or be placed on separate physical hardware, to increase performance by offloading processing from your application server. An unmanaged RAS server is no longer available as an upgrade option. It is recommended that you upgrade to Crystal Reports Server instead. For more information, see Upgrade Options.

  The Crystal Reports Advanced Developer edition provided a performance-governed version of the unmanaged Report Application Server (RAS), which is suitable for smaller deployments with less complex reports and fewer user interaction requirements. This product is no longer available.

  Or, it was possible to license the unmana ged Report Application Server (RAS) on a processor basis, where it takes full advantage of your hardware. This product is no longer available.
• The separate report server process is encapsulated into a complete Enterprise architecture

  In the Crystal Reports Server or BusinessObjects Enterprise solution, an entire Enterprise architecture is added, which encapsulates the separate report server process (RAS). The managed Report Application Server (RAS) becomes only one server, among many other servers in the Enterprise architecture. This architecture provides a rich set of additional features, such as scheduling, load balancing, fail-over, and both vertical and horizontal scalability.

NOTE:  The red was added by me for emphasis.  For more information click here.

So there it is.  There is a limit of three simultaneous processing threads when you use Crystal Reports Embedded within a .NET or Java based application.

What if I need more scalability?

If you look over the product offerings available from SAP BusinessObjects, you will see that all the current offerings include the BusinessObjects platform. This means that you will need to purchase one of our server based product offerings in order to provide additional scalability.

There are a number of advantages to this platform.  The first is unlimited scalability.  One common problem we had in moving customers from an unmanaged environment to a managed environment was that certain parts of their application had to be rewritten.  With the platform, you need to "login", retrieve your report from a "repository" (instead of a filesystem).  You also wanted to make sure you are using the Page Server instead of the RAS Server (which had more overhead).

Now by requiring customers to move to a repository/platform based platform earlier, they are able to reap the benefits of a dedicated reporting environment

Here is what a basic architecture might look like if you upgrade to CR Server:

And here is one with BusinessObjects Enterprise:

How does this affect Runtime Distribution?

This does NOT affect your ability to create Crystal Reports and embedded them into your Visual Studio or Java based applications and distribute them out.  It is important however that you only distribute out the DLLs and JAR files listed in the RUNTIME.TXT file under the .../Crystal Reports/Help/en directory.

For more information you can also check out my previous post about this topic here.

Enjoy!

Android is a software platform and operating system for mobile application development that includes an middleware and key applications development module in it. For using tools and APIs, to develop an application on the Android platform Java programming language is being used. This OS is based on Linux operating system. It only supports the managed codes as the programs, not in native codes.

Qbit Systems has been initiated its development efforts to cater the niche segment of the Android development.

This platform is adaptable in 2D and 3D graphics as well as in VGA smart phone layouts it also supports a wide variety of connectivity technologies like Wi-Fi, Bluetooth, CDMA, etc. and some audio, video and images formats like MP3, gif, Mpeg, etc.

There is a SDK (Software Development Kit) is available to develop an application for using this platform. The SDK is having a few of development tools like debugger, documentation, libraries, etc. which can be used on Windows XP, Vista or X86 based platforms. Android is a complete multitasking environment where apps can run in parallel.

Courtesy: QBit Systems

La semana pasada, Apple lanzó el Programa Universitario del Desarrollador del iPhone (iPhone Developer University Program), una iniciativa gratuita orientada a ayudar a los institutos de educación superior que quieran enseñar sobre desarrollo para el iPhone y el iPod Touch. La iniciativa ha hecho levantar cejas y preguntas entre los desarrolladores existentes del iPhone con respecto al acuerdo de no revelación (NDA por su nombre en inglés) de Apple.

Actualmente, el NDA previene que los desarrolladores del iPhone discutan los detalles técnicos de programar para el iPhone, incluso con otros desarrolladores de aplicaciones que también están sometidos por el NDA. Se desconoce si Apple creará un acuerdo diferente para el programa universitario que permita específicamente discusiones o si el NDA actual tendrá algún tipo de enmienda para tomar esto en consideración. Muchos desarrolladores esperan que sea lo segundo, dado que las críticas hacia el NDA han sido muchas y coloridas desde que el kit de desarrollo de software está disponible.

El programa, disponible para acreditar a las instituciones en los Estados Unidos, le permite a los profesores crear equipos de desarrolladores para el iPhone de hasta 200 estudiantes que pueden desarrollar, probar, depurar y distribuir aplicaciones entre ellos o a través de la App Store. Serán capaces de tomar ventaja de todas las herramientas a las que los desarrolladores para el iPhone tienen acceso, incluyendo el iPhone SDK y recursos del iPhone Dev Center.

El programa estándar de desarolladores de Apple cuesta US$99 si se quiere probar las aplicaciones en un dispositivo, pero el programa universitario es gratuito y provee de los mismos beneficios. Apple también tiene, por $299, el programa de Desarrollo de Empresas, para corporaciones de más de 500 personas que deseen desarrollar sus propias aplicaciones. Para registrarse en el programa universitario, el registro debe hacerse por alguien que tenga la autoridad legal para involucrarse en esta clase de trato en representación de la universidad. Apple autenticará la existencia e identidad de todos los postulantes y sus instituciones.

Así lo demuestra la nueva versión 1.0 del entorno de desarrollo para Android que esta lista para descargarse para todos aquellos que estén pensando en crear software para esta plataforma, un año lleva su desarrollo y las expectativas son altas, la pregunta es si cumplirá o no, aunque podríamos decir que es muy prematuro para contestar, por lo que he visto de las aplicaciones que ya circulan por la red, se podría decir con cierta cautela que será todo un éxito la Android Market.

Nuevas habilidades para usar los sensores de los teléfonos Android, mejoras en el manejo de archivos de audio y el uso de las redes WiFi, nos trae esta nueva versión, y un comentario bastante friki se lee al final de las notas de este kit “We regret to inform developers that Android 1.0 will not include support for dot-matrix printers” (lamentamos informarle a los desarrolladores que Android 1.0 no incluye soporte para impresoras de matriz de puntos) y bueno es que al final de cuentas somos y seguiremos siendo Geeks.

Fuente: Informationweek

Google Android - An open source OS for mobile phones.

Google has launched it's new open source operating system for mobile phones. It's first phone to use this OS? T-Mobile HTC. (Named G1). This phone will be going on sale in October!

The OS is open for any developers to create applications for and the OS itself can be tailored for individual phones, networks and potentially user. Thirty four companies, including Google, have formed an alliance to promote Android and to develop features and handsets to take advantage of the platform. These companies include handset manufacturers such as LG HTC, Motorola and Samsung, chip firms such as Qualcomm and mobile networks like T-Mobile and China Mobile.

Google have made a Market for downloading applications, just like Apple's App Store for the iPhone. However, unlike Apple, Google's market will not require approval for applications.