Turn off Notification Hub in Azure Mobile Service to use Legacy Push

Currently when you create a new Windows Azure Mobile Service to send push notification(detailed information can be found in Get started with push notifications in Mobile Services ),  the  notification hub is by default integrated with your mobile service, we really want people to move away from the legacy push, however, for the rare cases…

0

注意Windows Phone代码文件的大小

我们收到一些反馈说某些Windows Phone应用程序无法通过应用程序商店进行安装。最终用户在安装应用的时候可能会遇到以下错误:   这个问题是因为过大的程序集文件导致的。如果你在开发应用的时候将所有的代码放在一个项目中,然后生成了一个很大的dll文件,这个dll可能会因为内存限制无法通过安装流程。目前为止,您可以通过将该dll分割成功多个小的dll来解决该问题。  

0

Take care of your Windows Phone code assembly size.

It’s reported that there are some Windows Phone applications which can’t be deployed onto the phones via Windows Phone store. The end user may encounter following error:   This problem can be caused by large size of the assembly. If you put all the code into one Widnwos Phone project and generate a single large dll. The dll…

0

如何在WP8应用中安全的使用Azure Blob存储

在前面一篇文章中,我们演示了在Windows store应用中安全的使用Azure Blob存储的步骤。Windows Phone上的步骤与此类似,只是在客户端代码以及设置方面有一些区别。但是为了方便读者阅读,我这里将就Windows Phone应用中如何安全的使用Azure Blob存储单独写一遍。这样对于Windows Phone开发者来说,只需要看这篇文章就够了。 我们已经在这篇文章中演示了在Windows Phone应用中使用Azure Blob存储的基本步骤,但是,对于一个商业应用来说,保证数据的安全性是很重要的一环。上次文章的代码中,对Blob的访问权限是通过PublicAccess来控制的,理论上如果PublicAccess设置为OFF,那么第三方就应该无法访问该Blob。但是这里有一个明显的安全隐患:我们的代码中明文存储了Access Key字符串,而通过一些反编译工具第三方能够很容易的获得这个字符串。如果这个Access Key被暴露的话,那么Blob中的内容就毫无秘密可言了。为此,我们需要找到一个可靠的办法来保证验证信息的安全。 为了解决这个问题,我们需要做到以下两条: 1.保证用户在未经授权的情况下无法获得验证信息。 2.用户通过授权后获得的验证信息不能被重复使用。 对于第一条,我们可以自己建立一个服务器,与该服务器的连接需要先进行身份验证,然后从服务器上获得用于连接Windows Azure 存储服务的验证信息。不过我们既然已经使用了Windows Azure,那么完全可以使用Windows Azure  云服务来为我们做同样的事情。 对于第二条,Windows Azure 存储服务提供了共享访问签名(Shared Access Signature)来保证验证信息的时效性。共享访问签名是一个在特定时间间隔内授予容器、Blob以及其他存储对象受限访问权限的 URI。也就是说,共享访问签名是一个URI, 客户端通过这个URI能够在规定时间内访问容器和Blob, 而超过了时间段的话这个URI就无效了,需要重新获取。 结合这两种方式,那么我们就能够实现对验证信息的保护了。我们将生成共享访问签名的代码放在Windows Azure云服务上,客户端通过访问云服务接口获得共享访问签名来访问Windows Azure存储服务商的Blob。 那么让我们来看看如果要安全的实现与前一篇文章相同的功能所需要完成的步骤。 一.   创建云服务并实现服务接口: 1. 从以下链接下载并安装Azure Cloud Service SDK For .NET: http://www.windowsazure.com/en-us/downloads/?sdk=net 针对不同的Visual Studio版本,您需要安装相应的SDK,这样在您的Visual Studio的项目模板中会出现Azure Cloud Service的模板。 2. 通过Azure Cloud Service模板创建一个Cloud服务,在项目向导中加入WCF Service Web Role:  …

0

WP8下解决加载图片所导致的内存不够问题的一些建议

由于Windows Phone 8设备的物理内存有限, SDK中限制了应用程序的最大可用内存。对于普通XAML 应用程序来说,512MB内存的设备提供给应用的最大内存是150MB,1GB或以上内存的设备提供给应用的最大内存是300MB. 即使在Menifest文件中提供了ID_FUNCCAP_EXTEND_MEM选项,也只是将512MB内存的设备的最大可用内存提高到180MB。在这么点内存中如果要加载大量图片就很容易出现内存不足的问题。这里我就如何解决加载图片所导致的内存不够问题提供一些建议: 1.       尽量避免加载不必要的高分辨率的图片。即使这个图片是JPG或PNG的格式,内部在渲染的时候还是需要解码为位图格式,所以仍然需要占用和分辨率相对应的大小的内存,比如说,一张图片分别1280×768的JPG图片可能只有几百K甚至几十K大小,但是如果将它解码到内存中,那就会占用固定的4MB(1280x768x4)左右的内存。如果图片过大的话,我们可以通过设定DecodePixelWidth/DecodePixelHeight来减少解码图像的大小,但是如果可能的话,最好的办法还是让服务端提供合适分辨率的图片。 2.       对于ImageOpened/ImageFailed等事件的处理函数,要记得及时释放。.NET应用很容易犯一个普遍的内存泄露问题,WP8应用也会有同样的问题:如果声明事件的那个对象生命周期长于处理函数所在的对象就会发生内存泄漏。所以对于这一类事件处理函数,您需要及时释放。  具体对这一类内存泄露的分析你可以参看以下链接:http://blogs.msdn.com/b/abhinaba/archive/2009/05/05/memory-leak-via-event-handlers.aspx 3.       在需要释放图片资源的时候将图片的UriSource设置为null。由于Window Phone内部对图片有基于Uri的缓存机制,如果你不将UriSource设为null,那么相应的缓存就得不到释放,这样的话跟内存泄露也没多大区别了。 4.       调用SetSource将图片Source设置为一个零字节的数组{0}来强制释放图片内存。由于图像数据都是分配在native端,在Manage端图片对象只有几十个字节,所以系统的垃圾回收机制通常不会及时回收数量这么小的内存。通过这种方式可以强制将图像内存卸载。 5.       在图片打开成功或失败之前不要尝试再加载图片,比如说再次设置UriSource或者调用SetSource。不管图片的加载是成功还是失败,你都必须等待图片加载完成之后再改变数据源。 6.       避免在一段代码中频繁的加载和卸载图片,比如说,在一个for循环语句中不停的加载和卸载图片来获取图片的某些信息。这种情况下系统的垃圾回收没有机会来将不用的图像内存释放掉。如果你的代码逻辑需要你这么做,你可以将每个图片加载卸载的操作都放在单独的一个Dispatcher工作项中完成。 这些都是WP8上应用程序加载图片导致内存不够的常见问题,希望能对你的开发有所帮助。    

0

Windows Phone App Studio之初体验

       不久前微软推出了基于 Web 的 Windows Phone (WP) 开发工具 Windows Phone App Studio,关于它的介绍是这样的:这款开发工具是面向“零基础”用户,可以通过浏览器访问Windows Phone App Studio开始使用。整个工具的使用非常简单,登录账户,根据向导输入需要的信息和内容,四步即可完成“开发”一个Windows Phone 8 应用程序。               在这个消息刚刚发布的时候,我还以为这个东西只是一个给开发者用来快速生成一些简单的WP 应用程序的工具,心想这种工具做出来的应用能有啥用处,这不是给人看笑话么,也就没有多关注。这几天想看看里面的生成的代码,于是就花了点时间去体验了一下,发现还是挺有意思的。          首先,这个东西完全颠覆了我原来的想法。确如微软所言,这是一个针对普通用户的开发工具,而且应该说,这是一个针对WP消费者的工具。它的目标不是帮助开发者做一个可以上架的应用,而是帮助用户在自己的WP设备上部署一个自己定义的应用,用户也可以不通过应用商店就将这个应用分享给其他用户。         我们知道目前在Window Phone 8平台上,普通消费者获得应用的方法只有一种,那就是通过应用程序商店。除非你是一名开发者,那么通过注册你的设备,你可以将自己开发的应用部署到您的WP设备上,但是最多也只能部署10个。那么WP App Studio是怎么样做到将一个非应用程序商店的应用部署到普通消费者的设备上的呢?其实这里面微软用的是企业应用部署方式。          对于企业应用部署方式,我这里简单的介绍一下:          所谓企业应用部署,就是企业绕过 Windows Phone 商店直接发布 Windows Phone 应用并将它们分发给员工或其他用户的方式,这Windows Phone 8新加的特性,这也是为什么WP App Studio上的应用只支持WP8的原因。要实现企业应用部署,通常需要以下步骤: 企业在开发人员中心注册与获取证书 将开发的应用使用获得的企业证书进行签名。 使用企业证书生成注册令牌(.AETX文件) 用户在手机上点击 AET 文件(或 AET 文件的链接)使手机加入公司账户 用户点击安装应用XAP (或  XAP 链接)完成安装。…

0