I am using WURFL, in order to detect form_factor
I enable the following capability.
- "form_factor"
However, once I run the code to detect form_factor, it crashes.
Then, when I look at source code
wurfl/wurfl-api/WURFL/VirtualCapability/IsSmartphone.php
wurfl/wurfl-api/WURFL/VirtualCapability/FormFactor.php
I realize I need to enable rest of the capabilities.
- "ux_full_desktop"
- "is_smarttv"
- "is_wireless_device"
- "is_tablet"
- "pointing_method"
- "resolution_width"
- "device_os_version"
- "device_os"
- "can_assign_phone_number"
I was wondering, is this the complete list of capabilities which required, in order to support form_factor?
As I don't find any detailed documentation (https://www.scientiamobile.com/wurflCapability) regarding form_factor.
Disclaimer: Luca Passani, CTO #Scientiamobile. The company that produces WURFL and all WURFL APIs.
WURFL Users have access to support, so I invite you to reach out to ScientiaMobile through teh regular support channels.
Please make sure that you provide complete information about the API version you are using.
Related
I'm trying to write some complex Starlark rules that link and build multiple dynamic libraries on Linux using the (relatively) new cc_common APIs.
There seems to be 2 different ways you can create compile/link actions using this API:
Using the compile()/link() methods, which are relatively "high-level", and
Using the create_compile_variables()/create_link_variables() along with get_memory_inefficient_command_line() and then calling actions.run() directly with the generated command line.
In particualr, I'm trying to get #2 to work. My question is, how can I create the param_file to pass into create_link_variables? There doesn't seem to be any Starlark API for this.
https://docs.bazel.build/versions/1.1.0/skylark/lib/cc_common.html#create_link_variables
agoessling I have shared a couple of source files for you here
It should give you a pretty good idea of how this lower level cc_common API can be used end to end.
There are still known holes in this API, i.e. not everything possible with the built-in cc rules also possible through cc_common, but I would say 90% is available.
I am not associated with the Bazel team and the code is the result of my own digging and sniffing. No warranties, but it works for me. Let me know if you get stuck on something - I will try to help.
If you get an idea of how to do some of it better (prettier, more compatible with the built-in rules, more platform-independent, etc.) I am all ears. Good luck!
I used FindFirstUrlCacheEntry/FindNextUrlCacheEntry Win API to get Internet Explorer's history programmatically in C++.
Can you tell me how to get Microsoft Edge History using C++ (Windows API)?
Not possible at this point in time. Might want to use the 'suggestions routes' at some of the links below.
Developer Feedback Home - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer
Developer Feedback Twitter - https://www.twitter.com/msedgedev
Feature Suggestions - https://windowsphone.uservoice.com/forums/101801-feature-suggestions/category/18985-web-browsing
Healy in Tampa
The history is stored in \AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat. It uses Microsoft’s Extensible Storage Engine to store data. There is a C++ wrapper for accessing Extensible Storage Engine files I've used to access data from this file.
The "Containers" table inside WebCacheV01.dat tells which "Container_X" tables have type of "Content" or "History", as well as the Secure Directories and their order. You can use the ESEDatabaseView utility to view the data inside the WebCacheV01.dat file.
Back in the good old days of flex (anyone?) flash builder provided a tool for generating the clients model based on the server model. Is there something similar for generating, say an ember's app model, based on the odata metadata?
datajs documentation does mention the subject. Though the reference for OData.read used in the sample doesn't say explicitly that it interprets the metadata somehow, it seems implied. You'll have to verify that.
It does take an optional metadata object however, suggesting there exists a formal representation for metadata to the library -- I would imagine generated via OData.read. Documentation seems non-existent. I don't know what that looks like.
From there, you should be able to further transform the model to something suitable for Ember.
(datajs is a low-level javascript library that implements client-side OData operations.)
I also know that JayStack provides a JaySvcUtil, a CLI process assembly (.NET program) that extracts metadata. The destination format is JavaScript code, though the model it uses is specific to JayData. Still, you may be able to work from there.
As mentioned by Maya, Microsoft provides the OData Client Code Generator, which generates .NET proxies. Might be more difficult to transform that.
If none of these work for you (which is actually likely), you can always parse the $metadata resource yourself -- I believe it always uses an XML representation in all current versions of OData.
If you need to do it dynamically in the browser, use DOMParser or XMLHttpRequest. More information.
If you can do it statically, then by all means do so -- it's simply best for performance. In this case, you can use whatever language and runtime tools you want to fetch, parse, transform and re-serialize the model.
The format (CSDL) is specified for OData here (v4) and here (v3).
Finally, check out this list, something new may appear that better fits your needs.
There are two suggestion which may help you.
1, OData provide client code generator to generate client-side proxy class. Just need to pass metadata url, .net client code will be generate for you. You can follow the following blog:
http://blogs.msdn.com/b/odatateam/archive/2014/03/11/how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class.aspx
2, If the model means "EdmModel", you can just de-serialize $metadata. OData reader can de-serialize the $metadata to IEdmModel, which can be used in client side. The following is sample code:
HttpWebRequestMessage message = new HttpWebRequestMessage(new Uri(ServiceBaseUri.AbsoluteUri + "$metadata", UriKind.Absolute));
message.SetHeader("Accept", MimeTypes.ApplicationXml);
using (var messageReader = new ODataMessageReader(message.GetResponse()))
{
Model = messageReader.ReadMetadataDocument();
}
I want to select incoming calls based on user input. E.g. by matching the telephone number to the user input number. To get user input number I used Java.
What are the best hardwares supporting to this requirement. I guess this hardware should allow us to call API and get current caller number. Then we can do the selection part using Java. After that we can another API method ans allow that call to proceed.
Let me know about the suitable hardware for this.
You have a number of options depending on how your incoming calls are presented - if you are lucky enough that they are coming in to a PABX which has some form of computer telephony interface (CTI) then you just need to interface your Java app to the PABX (many Cisco, Avaya etc pABX's will support some form of CTI).
If your calls come in on a standard line to a standard phone today, then you can either replace the phone with a simple commercial PABX (if you have the budget) or you can create your own PABX using one of the open source options and some line cards - see the answer to this question for a link to an example line card for the open source Asterix PABX:
https://stackoverflow.com/a/18220055/334402
If you have the option of a hosted VoIP 'telephone line' then it would be worth contacting your provider as they may provide hosted CTI options, saving you the need to get dedicated hardware.
What does it take to build a Native Client app from scratch? I have looked into the documentation, and fiddled with several apps, however, I am now moving onto making my own app and I don't see anything related to creating the foundation of a native client app.
Depending on the version of the SDK you want to use, you have a couple of options.
Pepper 16 and 17: use init_project.py or use an example as a starting point
If you are using pepper_16 or pepper_17, you will find a Python script init_project.py in the project_templates in the SDK. It will setup up a complete set of files (.cc, .html, .nmf) with comments indicating where you need to add code. Run python init_project.py -h to see what options it accepts. Additional documentation can be found at https://developers.google.com/native-client/pepper17/devguide/tutorial.
Pepper 18 and newer: use an example as the starting point
If you are using pepper_18 or newer, init_project.py is no longer included. Instead you can copy a very small example from the examples directory (e.g., hello_world_glibc or hello_world_newlib for C or hello_world_interactive for C++) and use that as a starting point.
Writing completely from scratch
If you want to write your app completely from scratch, first ensure that the SDK is working by compiling and running a few of the examples. Then a good next step is to look at the classes pp::Module and pp:Instance, which your app will need to implement.
On the HTML side, write a simple page with the EMBED element for the Native Client module. Then add the JavaScript event handlers for loadstart, progress, error, abort, load, loadend, and message and have the handlers write the event data to, e.g., the JavaScript console, so that it's possible to tell what went wrong if the Native Client module didn't load. The load_progress example shows how to do this.
Next, create the manifest file (.nmf). From pepper_18 and onwards you can use the generate_nmf.py script found in the tools/ directory for this. If you want to write it from scratch, the examples provide examples both for using newlib and glibc (the two Standard C librares currently supported). See hello_world_newlib/ and hello_world_glibc/, respectively.
If you haven't used a gcc-family compiler before, it is also a good idea to look at the Makefile for some of the examples to see what compiler and linker flags to use. Compiling both for 32-bit and 64-bit right from the beginning is recommended.
Easiest way is to follow the quick start doc at https://developers.google.com/native-client/pepper18/quick-start, in particular steps 5-7 of the tutorial ( https://developers.google.com/native-client/pepper18/devguide/tutorial ) which seems to be what you are asking about.